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PREFACE 


This  report  documents  a  Federal  Aviation  Administration  controller 
eyaluatiofi  of  air  traffic  control  (ATC)  Data  Link  Services  planned 
for  implementation  in  the  en  route  ATC  system. 

The  main  body  of  the  report  includes  a  detailed  description  of  the 
objectives  of  the  study  and  of  the  technical  approach  and  test 
methods  that  were  used,  in  addition,  the  combined  results  of  the 
study,  conclusions,  and  recommendations  are  presented.  There:  are 
four  appendixes  to  the  report.  These  appendixes  are  referenced  in 
the  main  body  of  the  report  and  include  documentation'  of  the 
controller  inputs  used  to  deliver  the  test  services,  controller 
questionnaires,  airspace  configurations,  and  controller  discussion 
issues . 
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EXECUTIVE  SUPIARY 

INTRODUCTION. 

The  Federal  Aviation  Administration  (FAA)  is  pursuing  an  initiative 
to  develop  and  implement  a  Data  Link  System  intended  to  enhance 
communications  between  ground-based  air  traffic  control  (ATC)  and 
airborne  systems.  By  providing  digital  information  transfer  with 
the  ability  to  discretely  address  individual  aircraft,  Data  Link 
is  expected  to  relieve  frequency  congestion  on  existing  voice  radio 
channels  while  increasing  the  overall  safety  and  productivity  of 
the  ATC  system. 

To  insure  that  the  introduction  of  Data  Link  will  have  a  positive 
impact  on  ATC,  the  FAA  is  conducting  research  to  guide  system 
design  efforts  and  evaluate  the  benefits  of  Data  Link  to  the  ATC 
system.  The  Air  Traffic  Data  Link  Validation  Team  (ATDLVT)  has 
been  formed  to  participate  in  the  research.  The  team  consists  of 
full  performance  level  controllers  representing  a  variety  of  FAA 
field  ATC  facilities. 

Mini  studies  are  being  conducted  under  realistic  conditipns  which 
simulate  the  essential  components  of  controller  tasks  associated 
with  the  services.  The  goal  of  these  studies  is  to  identify 
service  delivery  methods  which  optimize  the  human  computer 
interface.  Operational  evaluations  are  also  being  jperformed  in 
order  to  verify  the  saiety  and  efficiency  of  Data  Link  utilizing 
real  ATC  systems  and  operational  scenarios. 

Two  mini  studies  were  conducted  at  ..the  FAA  Technical  Center  Data 
Link  test  bed  during  1988  to  develop  an  initial  set  of  en  route 
Data  Link  services.  In  April  1989,  an  operational  evaluation  of 
the  initial  en  route  Data  Link  services  was  performed  using  Full 
Performance  Level  air  traffic  controllers.  As  a  result  of  this 
evaluation  and  subsequent  ATDLVT  meetings,  specific  enhancements 
and:  changes  were  made  to  the  design  of  the  Qata  Link  services.  The 
ATDLVT  strongly  suggested  an  enhanced  scenario  capability  in  the 
FAA  Technical  Center  test  bed.  The  Washington  Air  Route  Traffic 
Control  Center  (ARTCC)  was  chosen  by  the  ATDLVT  as  the  airspace  for 
future  Data  Link  test  bed  evaluations  enabling  enhanced  scenarios. 
In  addition.  Data  Link  service  design  changes  were  suggested  by  the 
team.  The  team  also  expressed  their  continued  desire  for  the  use 
of  Data  Link  at  the  D-Controller  position  and  the  heed  for 
development  of  Data  Link  procedures. 

This  report  presents  the  results  of  the  third  FAA  controller  mini 
study  of  en  route  ATC  services  developed  for  implementation  on  the 
Data  Link  system.  This  study  follows  two  en  route  mini  studies, 
several  smaller  studies  using  the  en  route  Data  Link  test  bed,  and 
an  Operational  evaluation. 


OBJECTIVES. 

The  objectives  of  the  Novei^er  en  route  ATDLVT  meeting:  Include  the 
following  Items: 

1.  ATDLVT  evaluation  of  the  new  Washington  ARTCC  airspace  test 
bed’  Implementation. 

2.  kTDLVT  evaluation  of  recent  refinements  to  the  Data  Link 
se^lce  (ieslgns . 

3.  ATDLVT  evaluation  of  the  preliminary  communications  backup 
downlink  design. 

4 .  Preliminary  ATDLVT  evaluation  and  determination  of  the  NAS  and 
Data  Link  functions  the  D-cpntroller  may  perform  In  a  Data  Link 
systein. 

5.  Preliminary  discussion  of  formal  Data  Link  operational 
procedures.. 

6.  Determine  how  collected  data  can  be  used  to  help  develop 
performance  measures  for  use  In  Data  Link  testing. 

The  results  of  the  meeting  and  test  activities  will  be  used  to 
enhance  the  current  Data  Link  test  bed  software  and  prpvidh  test 
guidelines  regarding  new  airspace  usage,  p-Controller 
resppnsiblllties,  Data  Link  procedures,  and  performance  measures 
fpr  future  testing  efforts. 

DATA  LINK  OPERATION. 

The  en  route  Data  LinH  test  bed  consists  of  the  NAS  Host  Computer 
System  (HCS)  used  ifi  conjunction  with  other  support  computer 
systems  to  provide  a  realistic  simulation  facility  for  the 
development  of  operational  and  procedural  concepts  of  the  initial 
eh  route  Data  Link  sewices.  The  following  services  and  functions 
have  been  incorporated  into  the  HCS  software  in  the  en  route  Data 
Link  test  bed. 

1.  Transfer  of  Communication  (TOC) .  This  service  provides  for 
handoffs  between  ATC  control  sectors.  The  controller  transmits, 
via  Data  Link,  the  necessary  handpff  data  to  the  pilot. 

2.  Altitude  Asslanmeht.  This  service  allows  for  the  uplink  of 
altitude  assigriments ,  and  interim  altitude  assignments . 

3 .  Menu  Text.  This  Data  Link  function  provides  the  capability  to 
store  repetitive  ATC  instructions  in  a  menu,  which  are  .easily 
uplinked  to  an  aircraft. 
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4.  Communications  Backup.  This  Data  Link  service  has  two  functions: 
c6nttolier-to-pilot  and  pilot-to-contrpller  message  processing.  This 
service  facilitates  free  format  messages  between  the  ground  and  air 
for  the  purpose  of  a  backup  to  the  voice  communication  channel . 


These  capabilities  are  intended  to  enhance  current  ATC  operations  by 
relieving  congestion  on  the  radio  voice  channels,,  providing  a  more 
reliable  communication  channel  thus  increasing  safety,  and  potentially 
reducing  the  controllers  workload. 

APPROACH. 

The  Washington  ARTCC  airspace  was  used  during  the  laboratory  sessions^ 
Two  scenarios  have  been  developed  and  will  be  referred  to  as  Scenario 
1  and  Scenario  2.  Scenario  1  consists  of  actual  traffic  recordings 
at  the  Washington  ARTCC.  Scenario  2  contains  aircraft  in  addition  to 
the  aircraft  in  Scenario  1.  The  National  Airspace  System  (NAS) 
Simulation  Support  Facility  was  used  for  pilot  simulation  to  afford^ 
a  high  level  of  realism.  ATDLVT  controllers  were  used  to  evaluate  the 
Washington  ,2^TCC  airspace  and  the  Data  Link  services. 

The  scenarios  were  used  in  a  series  of  test  runs  designed  to  review 
and  critique  the  service  designs.  Questionnaires  were  administered 
to  controllers  after  selected  test  runs.  Additional  data  coliection 
which  occurred  during  debriefing  sessions  included  structured 
discussions  to  elaborate  on  the  results  obtained  in  the  laboratory  and 
the  adequacy  of  the  test  scenarios,  and  the  operational  value  of  the 
tested  services i 

SUMMARY  OF  RESULTS^ 


The  Washington  ARTCC  airspace  provided  adequate  realism  for  the 
simulation  and  was  approved  by  the  ATDLW.  The  ATDLVT  suggested  minor 
enhancements  for  future  ATC  Data  Link  simulations> 


Recent  refinements  to  the  Data  Link  service  designs  were  reviewed  by 
the  ATDLVT.  A  detailed  analysis  of  the  test  results  is  included  in 
the  text  of  the  report.  These  refinements  included  the  automatic 
Transfer  of  Communication  (TOC)  function,  voice  check-in  requirements, 
generic  full  data  block  (FDB)  failure  displays,  plan  view  display 
(PVD)  settings,  status  list  display  states,  /OK  functions,  free  text 
(communications  backup)  recall,  the  altitude  timeshate  function,  and 
menu  text  referent  acceptability. 

A  brief  synopsis  of  the  refinements  test  results  indicates;  50  percent 
Of  the  ATDLVT  preferred  the  automatic  TOC  function,  voice  check-in 
remains  a  significant  unresolved  issue,  no  acceptable  generic  FDB  fail 
display  was  found  during  the  testing,  PVD  setting  displays  should  be 
Changed  to  reduce  display  clutter,  the  status  list  should  have  two 
display  states  -  full  and  default,  use  of  /OK  to  acquire  Data  Link 
eligibility  should  be  allowed  from  any  sector,  the  menu  text  referent, 
and  the  free  text  recall  functions  were  approved.  The  preferred 
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alternation  display  interval  for  timesharing  the  uplinked  altitude 
with  the  normally  displayed  altitude  in  the  FDB  is  1.5  Seconds. 
Preliminary  collected  data  suggest  that  altitude  tiroeshare 
transadtidns  will  not  significantly  impact  the  display  channel 
interface  capacity  in  the  near  term. 

Although  the  communications  backup  downlink  service  was  rated  "good,” 
numerous  comments  and  suggestions  were  submitted  by  the  ATDLVT 
concerning  the  design.  Future  testing  will  be  required  in  order  to 
evaluate  these  changes. 

Communications  backup  and  hahdoff/TOC  were  cited  as  the  most  likely 
candidates  for  p-controller  responsibility.  The  ATDLVT  also  suggested 
that  the  D-controller  could  perform  Data  Link  status  list  maintenance 
and  monitor  for  Data  Link  failures. 

Discussions  on  rules  for  Data  Link  message  transmissions  resulted  in 
several  recommended  procedures  related  to  multiple  Data  Link  uplinks, 
resolving  failed  transactions,  and  pilot  check-in.  Although  many 
proposed  procedures  were  discussed ,  no  consensus  was  reached .  Further 
testing  is  required. 

Performance  measures  were  collected  and  are  listed.  The  data  are 
currently  being  reviewed. 

.  RECOMMENDATIONS. 

The  Washington  ARTCC  adaptation  should  continue  to  be  used  in  the  en 
route  Data  Link  test  bed.  A  Data  Link  test  bed  capable  of  interfacing 
eh  route  and  terminal  computer  systems  should  be  established. 

An  initial  contact  procedure  should  be  developed.  Discussions  and 
testing  with  pilots  and  controllers  should  be  conducted  to  address 
the  issue  of  voice  check-in,  and  to  define  associated  operational 
requirements.  The  initial  contact  procedure  was  identified  as  a  high 
priority  item. 

All  Data  Link  functions  approved  by  the  ATdlvt  should  be  implemented 
in  the  en  route  test  bed  software  and  subjected  to  future  operational 
test  and  evaluation. 

A  generic  display  technique  for  alerting  the  controller  to  transaction 
failures  should  be  developed  and  tested. 

The  functional  design  and  use  of  the  Communications  Backup  downlink 
should  be  pursued  in  accordance  with  the  detailed  modifications  to 
the  design  identified  herein.  Furthermore,  pilots  and  controllers 
should  participate  in  developing  the  default  response  messages,  and 
in  developing  procedures  associated  with  the  function. 

Further  testing  should  be  conducted  to  develop  the  D-controller 
position  capabrlity  with  Data  Link,  in  support  of  that  requirement. 
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D-position  operational  responsibilities  should  be  identified  and 
tested,  and  new  traffic  scenarios  should  be  developed  to  increase 
sector  workloads  to  support  these  tests. 

Additional  testing  should  be  conducted  to  assess  the  effects  of  the 
Data  Link  altitude  timeshare  function.  The  display  channel  should 
be  tested  to  verify  that  the  1.5-second‘  alternation  is  maintained 
during  peak  heavy  loads. 

Controllers  and  pilots  should  jointly  develop  testable  procedures  for 
using  Data  Link  ATC  services.  The  procedures  should  then  be  evaluated 
in  the  test  bed. 
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The  purpose  of  this  report  is  to  provide  a  detailed  description  of 
the  en  route  Air  Traffic  Data  Link  Validation  Team  (ATDLVT) 
activities  conducted  during  Mini  Study  3.  Included  are  the  items 
and  issues  the  team  addressed  during  the  week  long  session.  Test 
conduct,  tes^t  items,  questionnaires,  and  results  of  the  testing  are 
included.  These  materials  are  intended  to  provide  all  the 
information  pertaining  to  the  November  1990  en  route  ATDLVT  Mini 
Study  3. 

1.2  BACKGROUND. 

In  response  to  the  National  Airspace  System  (NAS)  Plan  to  provide 
a  digital  Data  Link  between  ground  based  operations  and  aircraft, 
a  Data  Link  test  bed  has  been,  constructed  at  the  Federal  Aviation 
Administration  (^AA)  Technical  Center  to  support  the  development 
of  en  route  Air  Traffic  Control  (ATC)  Data  Link  services. 

The  en  route  Data  Link  test  bed  consists  of  the  NAS  Host  Computer 
System  (HCS)  used  in  conjunction  with  other  support  computer 
systems  to  provide  a  realistic  simulation  facility  for  the 
development  of  operational  and  procedural  concepts  of  the  initial 
en  route  Data  Link  services.  The  following  services  and  functions 
have  be^n  iricorporated  into  the  HCS  software  in  the  en  route  Data 
Link  test  bed. 

a.  Transfer  of  -  Communication  f TOC^ .  This  service  provides 
for  handoffs  between  ATC  control  sectors.  The  controller 
transmits,  via  Data  Link,  the  necessary  handoff  data  to  the  pilot. 

b.  Altitude  Assignment.  This  service  allows  for  the  uplink 
of  altitude  assignments,  and  inteicim  altitude  assignments. 

c.  Menu  Text .  This  Data  Link  function  provides  the  capability 
to  store  repetitive  ATC  instructions  in  a  menu,  which  are  easily 
uplinked  tP  an  aircraft. 

d.  Communications  Backup.  This  Data  Link  service  has  two 
functions:  controller-to-pilot  and  pilot-to-controller  message 
processing.  This  service  facilitates  free  format  messages  between 
the  ground  and  air  for  the  purpose  of  a  backup  to  the  voice 
communication  channel. 

These  capabilities  are  intended  to  enhance  current  ATC  operations 
by  relieving  congestion  on  the  radio  voice  channels,  providing  a 
more  reliable  communication  channel,  thus,  increasing  safety,  and 
potentially  reducing  the  controllers  workload. 


Two  Mini  Studies  were  conducted  at  the  FAA  Technical  Center  Data 
Link  test  bed  during  198^  to  develop  an  initial  set  of  en  route 
Data  Link  services.  In  April  1989,  an  operational  evaluation  of 
the  initial  en  route  Data  Link  se^^ices  was  performed  using  Full 
Performance  Level  (FPL)  air  traffic  controllers  (reference  1).  As 
a  result  of  this  evaluation  end  subsequent  ATDLVT  meetings, 
specific  enhancements  and  changes  were  made  to  the  design  of  the 
Data  Link  services .  . 

During  May  1990,  a  Data  Link  Service  Design  Validation  Micro  Study 
was  held  at  the  F^  Technical  Center  (reference  2).  The  purpose 
of  the  study  was  to  validate  design  changes  resulting  from  the 
operational  evaluation  and  subsequent  controller  meetings.  Many 
Data  Link  designs  were  validated  during  the  study  while  other 
design  and  test  conduct  issues  surfaced.  The  feedback  obtained 
from  the  ATDLVT  during  the  Data  Link  Service  Design  Validation; 
Micro  Study  strongly  suggested  an  enhanced  scenario  capability  in 
the  FAA  Technical  Center  test  bed.  The  , Washington  Air  Route 
Traffic  Control  Center  (ARTCC)  was  chosen  by  the  ATDLVT  as  the 
airspace  for  future  evaluations.  In  addition,  minor  Data  Link 
service  design  changes  were  suggested  by  the  teami  The  ATDLVT 
reviewed  the  Communications  Backup  Downlink  design  and  offered^ 
suggestions  for  implementatfon  in> the  test  bed  software.  The  team; 
also  expressed  their  continued  concern  for  the  use  of  Data  Link  at 
the  D-Controller  position  and  the  need  for  development  of  Data  Link 
procedures . 

1 . 3  OBJECTIVES . 

The  objectives  of  the  November  en.  route  ATDLVT  Mini  Study  3  include 
the  following  items: 

a.  Establish  an  operational -baseline  for  testing  Data  Link  in 
the  en  route  FAa  Technical^  Center  test  bed.  This  consists  of 
ATDLVT  evaluation  of  the  hew  'Washington  ARTCC  airspace 
implementation . 

b.  ATDLVT  evaluation  of  recent  refinements  to^the  Data  Link 
service  design.  This  involves  evaluation  of  the  changes  made  to 
the  Data  Link  software  as  a  result  of  the  spring  ATDLVT  meeting. 

C.  ATDLVT  evaluation  of-  the  preliminary  downlink  design.  This 
includes  using  the  en  route  test  bed  and  the  ATDLVT  to  evaluate 
the  communications  backup  downlink  service  design. 

d.  Preliminary  ATDLVT  evaluation  of  the  ”D-side'* 
effectiveness.  Determine  what  NAS  and  Data  Link  functions  the 
D-side  can  perform  in  a  Data  Link  system.  Gain  insight  as  to  how 
the  D-side  may  increase  a  sector's  effectiveness.  Obtain  ideae  for 
use  in  testing  the  D-side  effectiveness  in  future  Data  Link 
evaluations . 
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e.  Preliminary  discussion  of  formal  Data  Link  operational 
procedures .  Use  ATDLVT  to  draft  an  initial  set  of  formal  Data  Link 
procedures . 

f.  Collect  data  from  the  NAS  HCS,  the  VAX  computer,  and  the 
NAS  Simulation  Support  Facility  (NSSF)  computer  system  to 
determine  how  the  data  can  be  used  to  help  develop  performance 
measures  for  use  in  Data  Link  testing.  (A  set  of  Data  Link  measures 
was  developed  for  the  operational  evaluation  (see  reference  3)  . 
The  current  effort  is  intended  to  enhance  these  measures  and 
develop  new  measures  for  upcoming  Data  Link  tests.) 

The  data  collected  in  items  2 ,  3 ,  and  possibly  4  above  will  be  used 
as  input  to  the  Data  Link  portion  of  the  Eh  Route  Software 
beveippment  and  Support  (ERSDS)  contract.  The  requirements  for  the 
Data  Link  portion  of  the  ERSDS  contract  are  detailed  in  the 
Functional  Specification  for  ATC  Data  Link  Service  Implementation 
in  the  HCS  (reference  4).  In  addition,  the  results  of  the  meeting 
will  be  used  to  enhance  the  current  Data  Link  test  bed  software  and 
provide  test  guidelines  (i.e.,  hew  airspace  usage,  D-Controller 
responsibilities.  Data  Link  procedures,  ahd  performance  measures) 
for  future  testing  efforts. 

1 .  4  ■  TEST-  ENVIRONMENT . 

The  Washingtph  ARTCC  airspace  was  used  during  the  laboratory 
sessions.  Two  scenarios  have  been  developed  for  the  Washihgtpn 
ARTCC  airspace  and  will  be  referred  to  as  Scenario  1^  and  Scenario 

2 .  Scenario  1  consists  of  actual  traffic  recordings  at  '  the 
Washington  ARTCC  and  is  somewhat  ee^sier  than  the  other  scenario, 
scenario  2  contains  aircraft  in  addition  to  the  aircraft  in 
Scenario  1  and  is  slightly  more  difficult  than  Scenario  1. 

The  pilot  side  of  the  tests  was  supported  by  the  NSSF.  The  NSSF 
provides  a  better  level  pf  realism  than  does  Dynamic  Simulation 
(DYSIM)  available  on  the  HCS.  With  the  NSSF,  pilots  are  physically 
located  ih  a  room  apart  from  the  controller  laboratory  and  aircraft 
maneuvers  are  simulated  with  greater  accuracy  thah  with  DYSIM.  The 
NSSF  enabled  the  ATDLVT  to  fetter  evaluate  the  realism  of  the  en 
route  test  bed  and  provided  an  additional  data  cpllection  ahd 
reduct ion>  capability. 

2.  METHOD. 

2.1  PARTICIPANTS. 

The  eh  route  members  of  the  ATDLVT  were  used  as  the  test  subjects. 
These  cohtr oilers  were  used  due  to  their  expertise  with  the  Data 
Link  service  design.  In  addition,  there  were  fPur  facilitators, 
one  at  each  Sector  position,  to  help  with  controller  questions. 
The  facilitators  consisted  of  engineer ihg  staff  familiar  with  the 
Data  Link  services  and  test  bed  scenarios.  All  facilitators  were 
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familiar  with  the  purpose  and  conduct  of  each  test  run.  The 
facilitators  were  also  responsible  for  recording  any  controller 
comments  or  scenario/ system  problems  encountered  during  the  test 
runs . 

2.2  SIMUIATION  FACILITIES. 

2.2.1  NSSF  and  VAX  Laboratory. 

In  this  study  the  NSSF  was  the  -target  generator  which  produced 
radar  targets  in  the  En  Route  Laboratory.  Physically,  the  NSSF 
consists  of  two  SEL  computers  and  the  Simulator  Pilot  Complex.  The 
NSSF  permits  real-time,  interactive  simulation  of  en  route  and 
terminal  airspace.  It  can  be  configured  to  match  a  facility's 
current  operations  by  emulating  existing  traffic  densities  and 
mixes,  radars,  navigational  aids,  and  communications.  It  has  the 
ability  to  examine  proposed  changes;  different  routes  and 
procedures,  additional  runways,  modification  of  separation 
standards,  additional  traffic  demands,  and  new  technology  such  as 
Data  Link,  Microwave  Landing  System  (MLS),  etc. 

Maps  and  routes  with  display  information  based  upon  either  present 
or  proposed  operations  are  used  for  simulated  sectors  and  their 
displays.  Patch- in  telephone  commuhications  and  computer  linking 
serve  to  simulate  sector  operation  in  a  realistic  fashion.  Where 
available,  ah  analysis  of  the  subject  facility's  past  flight  strips 
serves  to  ensure  an  appropriate  mix  of  aircraft,  routes,  and 
identifiers. 

The  Simulator  Pilot  Complex  houses  the  simulation  pilots 
(.operators)  and  their  aircraft  control  consoles.  In  this  study, 
the  simulator  operators  communicated  via  voice  and  Data  Link  with 
the  controllers  in  the  en  route  laboratory  and  converted  their 
traffic  control  directives  into  keyboard  entries  to  initiate  the 
required  computer  simulation  of  the  desired  aircraft  response.  All 
aircraft  responses  are  modifiable  and  are  programmed  to  be 
consistent  with  the  type  of  aircraft  which  is  being  simulated.  The 
"pilots"  also  initiated'  communications  to  the  controllers  in  the 
en  route  laboratory  and  provided  them  with  any  required  procedural 
reports,  emergency  notifications,  etc. 

When  Data  Link  is  fielded  operationally,  all  Data  Link  related 
communications  with  equipped  aircraft  will  be  routed  through  Ground 
Data  Link  Processors  (GDLP) ,  located  in  each  of  the  En  Route  Air 
Traffid  Control  centers.  In  this  study,  the  function  of  the  GDLP 
was  simulated  by  a  VAX-11/750  computer,  which  interfaced  to  a  Host 
computer  INTO/INTI  Interfacility  port  via  a  custom  Motorola  VME 
processor.  Aircraft  Data  Link  functions  were  simulated  via  VAX 
"Pilot"  cathode  fay  tube  (CRT)  terminals,  positioned  one'  per 
simulated  sector  in  the  NSSF  Simulator  Complex,  paired  with  the 
target  generator  terminals  utilized  to  simulate  aircraft  state 
functions.  Each  VAX  Pilot  terminal  displayed  all  Host  computer 
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initiated  Data  Link  services  for  equipped  aircraft  in  its  assigned 
sector,  and  provided  means  of  generating  pilot  responses  to  those 
services.  Additionally,  the  VAX  Pilot  terminals  were  used  to 
generate  aircraft  initiated  Emergency  Backup  Communications  Data 
Link  messages  (see  figure  L) . 

2.2.2  Eh  Route  System  Support  Faciiitv  (ESSF)  Display  Laboratory. 

The  ESSF  Display  Laboratory  Is  used  to  perform  testing  and  analysis 
to  support  ARTCC  operations  and  development  programs.  It  consists 
of  two  ARTCC  configurations,  each  with  11  radar  controller 
positions.  One  configuration  is  driven  by  the  Computer  Display 
Channel  (CDC)  and  the  other  by  the  Display  Channel  Complex  (DCC) . 

The  Washington  ARTCC  adaptation  was  implemented  to  run  in  the  CDC 
side  of  ESSF  Display  Laboratory.  This  adaptation  was  used  to 
configure  sector  conti^oller  positions,  adapt  airspace,  prepare 
traffic  samples,  and  configure  other  peripheral  devices  needed  to 
conduct  the  Data  Link  tests.  In  the  Display  Laboratory,  4  of  the 
il  radar  controller  positions,  which  included  the  D-controller 
positions,  were  configured  as  active  control  positions.  These 
positions  are  depicted  in  figure  2.  The  controller  positions  #30 
and  #31  were  adapted  as  low  altitude  control  sectors,  controller 
position  #32  was  configured  as  a  high  altitude  control  sector,  and 
controller  position  #60  was  configured  as  an  intermediate  control 
position. 

2 . 2 . 2 . 1  Support  Systems . 

The  other  systems  that  were  used  to  support  the  realism  of  the  Data 
Link  tests  were  the  AMECOM  Communication  System  and  Flight  Data 
Input  Output  (FDIO)  System. 

2 . 2 . 2 .  i .  1  . AMEGOM  Communication  System . 

The  AMECOM  Communication  System  is  a  microprocessor  controlled 
voice  communications  system  that  was  used  to  provide  the 
communication  link  between  the  controller  positions  and  simulated 
pilot  positions  used  in  the  Data  Link  simulations.  The  system 
provided  both  radio  and  intercom/ interphone  capability  at  the 
controller  positions  and  only  radio  (simulated)  capability  at  the 
simulated  pilot  positions.  The  system  is  programmed  for  scenarios 
and  can  be  reconfigured  for  different  assignments. 

The  AMECOM  system  also  provided  the  capability  for  voice  recording 
and  data  collection  for  the  controller  positions. 

2.2.2. 1.2  Flight  Data  Input  Output  System  (FDIO). 

The  FDIO  system  is  the  NAS  hardware  that  provides  flight  data  entry 
and  printout  capability  in  the  ARTCGs.  It  also  distributes  flight 
plan  data,  weather  information,  and  general  information  between  ATC 
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FIGURE  1.  DATA  LINK  TEST  BED 
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FIGURE  2.  CDC  ESSF  DISPLAY  LABORATORY  CONFIGURATION  FOR  THE 
LEESBURG  ARTGC  DATA  LINK  SIMULATION 


facilities.'  The  system  was  used  in  the  ESSF  Display  Laboratory  to 
provide  at  each  controller  position  printed  flight  plan  data  on 
flight  strips  via  the  flight  strip  printers.  The  FDIO  system 
improved  the  realism  of  the  Data  Link  tests  by  providing  the 
controller  with  th©  capability  to  receive  and  enter  flight  plan 
data,  on  the  traffic  samples. 

2.3  -RESEARCH  DESIGN. 

The  Novei^er  1990  ATDLVT  meeting  consisted  of  briefings,  group 
discussions,  and  laboratory  sessions.  The  laboratory  sessions 
utilized  the  FAA  Technical  Center  en  route  Data  Link  test  bed  which 
provided  a  reali.feic  simulation  facility  for  the  ATDLVT  to  develop 
the  en  route  Datu.  Link;  services.  Prior  to  each  laboratory  session 
the:  controller  team  was  briefed  on  what  was  to  be  accomplished 
during  the  test  session.  To  ensure  that  testing  was  effective, 
each  controller  was  given  material,  that  explained  each  step  of  the 
test.  During  testing,  a  facilitator  was  present  at  each  sector 
position  to  answer  any  controller  questions.  Each  facilitator  had 
a  Data  Link  Laboratory  Session  Sheet  that  contained  the  purpose  of 
each  test  and  the  proper  conduct  that  had  to  be  followed  to  obtain 
the  desired  results. 

Following  the  test  sessions,  a  debriefing  session  took  place  to 
discuss  the  issues  raised  during  the  laboratory  test  session. 

2t...4.-  EBQg.EPyRE. 

The  laboratory  sessions  consisted  of  three  4-hour  sessions.  Two 
controllers  were  assigned  to  each  of  the  four  controller  positions . 
One  acted  as  the  R-rcontroiler  and  the  other  acted  as  the 
D-controiler.  During  the  tests  their  positions  were  switched,  as 
described  in  the  Data  Link  Laboratory  Session  Sheets,  to  enable 
each  controller  to  play  both  the  R  and  D  roles. 

2  vSIMmATIQNJSmis . 


Day  1 
Run  #1 

Purpose;  To  familiarize  the  ATDLVT  with-  Data  Link  and  the  sector 
airspace  in  the  Scenarios,  and  to  allow  the  controller  team  to 
observe  the  timeshare  of  altitude  data  in  the  fuil  data  block  at 
a  1-second  interval. 


Run  #2 

Purpose:  To  allow  the  controller  team  to  evaluate  the  Automatic 
Transfer  of  Communication  displays,  use  the  Data  Link  /OK  function 
With  and  without  the  S  option,  observe  Held  TOC  messages,  and  Send 
Data  Link  Eligibility  with  and  without  the  new  I  optidh. 
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Run  #3 


Purpose:  To  familiarize  the  controller  team  with  the  new  Leesburg 
airspace  and  collect  baseline  data  (i.e. ,  no  Data  Link  timeshare) 
for  the  full  data  block  timeshare  CDC  evaluation. 

Day  2 

Run  #1  and  #2 

Purpose:  To  evaluate  the  Altitude  Timtshare  interval,  the  Full 
Data  Block  Failure  Display  Options,  the  Menu  Text  Referent  in  the 
Status  List,  and  the  Free  Text  Recall  (items  5,  6,  7,  and  8  on  the 
Testbed  Software  Validation  Questionnaires) . 

Run  #3 

Purpose:  To-  evaluate  which  Data  Link  services  should,  and  should 
not  be  displayed  in  the  Data  Link  status  list. 

Day  3 

Run 

Purpose:  To  evaluate  the  Communications  Backup  Downlink  service. 

Run  #2 

Purpose:  To  evaluate  the  p-positioh  Data  Link  functions. 

Run  #3 

Pu^ose:  To  collect  Data  Link  information  for  the  Full  Data  jBlock 
timeshare  CDC  evaluation  and  data  for  Data  Link  measures 
evaluation. 

2.6  TRAFFIC  sMPLES. 

The  scenarios  used  in  the  Data  Link  tests  were  prepared  from  actual 
flight  plan  data  collected  from  the  Washington  ARTCC.  The  flight 
plan  data  sample  originated  from  air  traffic  in  the  western  part 
of  the  Washington  ARTCC  airspace.  The  traffic  load  of  the  sample 
ranges  f*rom  low  to  moderate.  The  sample  contained  89  flights  and 
included  General  Aviation  (GA) ,  commercial,  and  military  flight 
plan  data.  Two  different  scenarios  were  prepared  from  the  sample. 
This  was  accomplished  by  changing  some  of  the  flight  plans  and 
adding  new  flight  plans.  All  aircraft  in  the  traffic  scenarios  were 
designated  as  Data  Link  equipped. 

The  flight  plan  data  for  each  scenario  was  stored  on  a  simulation 
(SIM)  tape.  During  each  test  run,  th®  flight  plan  data  were  read 
from  the  SIM  tape  to  the  HCS  to  display  aircraft  targets  on  the 
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four  controller  position  plan  view  displays.  Each  traffic  scenario 
was  prepared  to  runs  a  tnaximum  of  ?0  minutes. 

In  the  scenarios,  the  traffic  in  each  of  the  four  controller 
sectors  presented  different  situations  for  each  controller.  The 
traffics  in  the  two  low  altitude  sectors  consisted  of  a  mixture  of 
GAyand  commercial  aircraft.  In  these  two  sectors,  there  were 
overflights,  arrivals  and  departures  to  and  from  airports  within 
the  sectors.  The  traffic  in  the  intermediate  and  high  altitude 
sectors  were  composed  of  military  and  commercial  overflights.  The 
nundser  of  aircraft  in  each  of  the  four  scenarios  were  89  in  the 
first  scenario  and  100  in  the  remaining  three  scenarios. 

The  traffic  in  the  low  sectors  provided  interaction  between  the 
two  low  altitude  sectors  and  the  intermediate  altitude  sector. 
Whereas,  the  traffic  in  the  intermediate  sector  provided 
interaction  between  the  low  and  high  altitude  sectors.  However, 
there  was  no  interaction  between  the  low  altitude  sectors  and  the 
high  altitude  sector. 


Different  methods  were  used  for  collection  of  data  from  the  ATDLVT 
members.  The  first  was  the  use  of  questionnaires  immediately 
folidwing  ©vei^  test  run.  Each  controller  answered  specific 
questions  and  provided  comments  about  the  issues  raised  during  the 
test  run.  The  .questionnaires  were  completed  in  the  laboratory  at 
the  sector  position.  The  controller  questionnaires  used  in  the  Mini 
Study  are  provided  in  appendix  A  of  this  document. 

After  the  test  runs ,  the  ATDLVT  members  were  taken  to  a  debriefing 
room  where  the  test  items  were  discussed  among  the  group  members 
and  engineering  staff.  During  these  discussions  the  individual 
questionnaire  results  collected  during  the  test  runs  were  presented 
to  the  team  for  discussion  among  all  group  members.  Upon  mutual 
agreement  between  the  team  members  and  engineering  staff,  issues 
were  resplyed. 

In  addition  to  the  data  collected  from  the  controller  team,  the 
test  bed  computer  systems  record  large  amounts  of  data.  Certain 
data  collected  will  be  reduced  and  used  to  develop  measures  of  Data 
Link  performance.  The  purpose  of  the  data  collection  during  these 
tests  was  to  determine  which  data  can  be  collected  and  successfully 
reduced.  Special  emphasis  Was  placed  on  data  collected  by  the 
NSSF  since  most  of  the  data  collection  on  the  HCS  and  voice  systems 
in  the  test  bed  are  already  being  utilized  (see  reference  3) .  The 
NSSF  can  provide  a  wide  range  of  data,  therefore,  specific  NSSF 
data  collection  requirements  have  been  defined. 


3.  TEST  RESULTS. 

3.1  CONTROLLER  DISCUSSION  ISSUES. 

In  order  for  the  Data  Link  Development  Team  to  present  issues  to 
the  ATDLVT  which  require  discussion,  the  controller  discussion 
issue  (GDI)  format  was  initiated.  A  GDI  permits  the  controller 
team  to  address  a  specific  problem  with  the  benefit  of  a  suggested 
solution  from  the  Development  Team.  The  ATDLVT  may  elect  to  concur 
with  the  suggested  solution  or  dictate  one  of  their  own. 
Typically,  the  ATDLVT  will  discuss  approximately  10  of  these  GDI's 
in  addition  to  formal  test  runs  and  debriefings.  The  GDI's 
presented  to  the  ATDLVT  are  included  in  appendix  B.  The  GDI's 
contain  the  resolutions  obtained  by  group  consensus.  A  brief 
review  of  the  resolutions  indicates  that  the  ATDLVT  feels  that 
increased  design  and  development  time  should  be  assigned  to  the 
majority  of  these  issues  in  the  near  future. 

3.2  POST-EXPERIMENT  INTERVIEW  f DEBRIEFINGS K 
3.2. 1..  Washington  ARTGG  Airspace  Evaluation . 

ii 

During  previous  ATDLVT  evaluations  of  the  en  route  test  bed,  the 
Universal  Data  Set  (UDS)  airspace  used  for  Data  Link  simulations 
was  cited  by  the  controller  team  as  not  being  sufficiently 
realistic.  As  a  result  of  this  inadequacy,  the  FAA  Technical 
Genteir  eh  route  Data  Link  test  bed  scenarios  and  airspace 
adaptation  wete  changed  from  UDS  to  the  Washington  ARTGG  airspace. 
The  Washington  ARTGG  airspace  is  taken _  from  the  ARTGG  and  is 
identical  to  that  used  in  the  field.  As  a  result  of  the  new 
airspace,  neW  traffic  patterns,  or  scenarios,  were  developed. 
Scenario  i  contains  air  traffic  taken  from  actual  tapes  of  traffic 
recorded  in  Washington  ARTGG.  The  other  scenario  uses  the  same 
aircraft  appearing  at  different  times,  and  some  new  aircraft  to 
increase  the  level  of  difficultly  providing  the  controllers 
slightly  different  traffic  patterns. 


The  Data  Link  test  bed  uses  four  sectors  from  the  Washington  ARTGG 
adaptation.  In  addition  to  these  sectors,  one  ghost  sector  is  used 
to  initiate  air  traffic  into  the  active  sectors  and  another  is  used 
to  receive  traffic  that  is  leaving  the  four  active  sectors.  During 
the  study >  the  controllers  evaluated  the  new  airspace  and  scenario 
implementation  in  the  Data  Link  test  bed  and  found  it  to  be  a  very 
realistic  environment  to  test  the  Data  Link  services.  All  the 
controllers  were  in  agreement  that  the  en  route  test  bed  provided 
tlie  level  of  realism  heeded  for  future  testing  efforts. 

One  problem  arose  with  the  implementation  of  the  Washington  ARTGG 
airspace.  The  controllers  found  that  with  the  increased  complexity 
of  the  sector  airspace  came  a  proportionate  increase  in  the  time 
it  took  to  learn  the  specifics  of  the  airspace.  The  controller 
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team  suggested  that  during  future  test  sessions  sufficient  training 
time  be  allocated  to  teaching  the  subject  controllers  the  airspace. 

In  addition  to  the  airspace  evaluation,  the  scenarios,  or  traffic 
patterns,  were  also  assessed  by  the  controller  team.  The 
controller  rating^S  on  Scenarios  1  and  2  are  given  in  figure  3 . 
Scenai^io  l  was  rated  ae  a  low  workload  scenario,  while  Scenario  2 
was  rated  more  difficult  with  a  moderate  to  high  workload  rating. 
The  controllers  felt  more  workload,  stress,  and  were  generally 
busier  with  Scenario  2  than  Scenario  1  (see  figure  4j .  In 
addition,  the  controllers  felt  they  performed  better  in  Scenario 
i  than  Scenario  2.  From  these  data  it  was  concluded  that  Scenario 
1  would  be  used  for  controller  training  and  Scenario  2  would  be 
used  for  actual  testing  during  future  evaluations. 

In  addition,  to  the  ratings,  the  controllers  were  asked:  What 
suggestions  would  you  make  to  improve  this  scenario?  Their 
comments  for  Scenario  I  and  Scenario  2  were  as  follows : 


Scenario  1  Controller  Comments: 

a.  "Not  being  familiar  with  the  area,  it  was  hard  going  back 
and  forth  to  get  the  proper  fixes  when  the  aircraft  needed  to  be 
put  in  trail. " 

b. .  "For  this,  particular  sector,  there  Could  have  been  more 
crossing  traffic  similar  to  Scenario  3 . " 

c.  "N733A  departed  DCA,  yet  it  came  to  us  descending  from 
FL310  to  EL210  when  it  should  have  been  climbing  to  FL210  from 
approximately  160." 

d.  "When  the  problem  is  all  voice  more  aircraft  are  needed 
than  this  problem,  generated  to  increase  controller  workload." 

Scenario  2  Controller  Comments: 

Si  "Good  scenario." 

b.  "Successive  departures  should  hot  increase  in  speed. "= 

C.  "Some  non-Data  Link  equipped  aircraft  should  be  included." 

d.  "Get  the  pilots  to  acknowledge  frequency  (voice) .  Make 
the  controllers  run  it  as  an  actual  situation  (grading  on 
counting  error  would  help,  no  controllers  like  to  admit  mistakes) . 
Establish  track  history  on  limited  data  blocks  before  entering 
sector.  Voice  check-ori!  I  like  the  warm  fuzzy." 

e.  "Eliminate  the  dropping  of  data  blocks  while  in  sector. 
The  pilots  need  to  be  on  frequency  when  the  Data  Link  symbol 
indicates  they  are.  When  using  the  "R"  feature,  the  climb  arrow 
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FIGURE  3.  CONTROLLER  WORKLOAD  RATINGS 


Harder  1 0' 


FIGURE  4.  CONTROLLER  SCENARIO  RATINGS 


needs  to  appear  when  the  WILCO  times  out .  The  failure  indication 
in  the  data  block  is  needed,  but  I  would  like  to  look  at  other 
methods . " 

Most  of  the  controllers  comments  addressed  scenario  problems,  which 
were  fixed  after  the  testing  was  complete.  One  comment  addresses 
the  lack  of  traffic  in  scenario  one.  This  supports  the  controller 
ratings  of  scenario  one  and  reinforces  its  use  as  a  training 
scenario.  Another  comment  addresses  including  non-Data  Link 
aircraft  in  the  scenarios ,  which  will  be  done  as  test  cases  warrant 
in  the  future. 

Scenario  2,  comment  "d”  addresses  a  voice  check-on  procedure  for 
TOC.  This  is  an  on-going  issue  that  the  controller  team  felt  must 
be  addressed.  They  came  to  the  conclusion  that  the  voice  check-on, 
or  initial  contact,  should  be  the  subject  of  the  next  en  route 
ATDLVT  meeting.  They  decided  that  a  2  Or  3  day  meeting  should  be 
established  to  design  the  en  route  initial  contact.  The 
engineering  staff  agreed,  and  it  is  generally  felt  that  a 
voiceless  TOC  under  current  procedures  cannot  be  realized  Without 
an  initial  contact  service. 

More  can  be  said  concerning  an  en  route  initial  contact  service. 
Some  controllers  would  like  to  see  a  voiceless  TOC,  while  others 
feel  that  a  voice  check-on  is  necessary  for  both  the  pilot  and 
controller.  The  voice  check-on  provides  both  parties  confidence 
that  the  aircraft  is  on  frequency. 

The  en  route  controllers  agreed  that  the  initial  implementation  of 
a  Data  Link  TOC  service  would  require  a  voice  check-on.  But,  they 
felt  that  after  enough  experience  with  Data  Link,  both  controllers 
and  pilots  would  build  enough  confidence  in  the  reliability  of  Data 
Link  and  voice  check-ins  could  be  phased-out.  If  this  were  the 
case,  there  is  currently  no  mechanism  included  in  the  TOC  design 
for  verifying  an  aircraft's  currently  assigned  altitude  on  check-in 
via  automation.  (The  controllers  felt  that  the  curreii.;  procedure 
which  requires  the  verification  of  an  aircraft's  currently  assigned 
altitude  would  not  be  eliminated  with  Data  Link.)  For  this  reason, 
the  ATDLVT  felt  that  an  en  route  initial  contact  service  should  be 
developed.  Its  primary  purpose  would  be  to  verify  the  aircraft's 
altitude,  via  automation,  when  the  aircraft  enters  a  sector's 
airspace. 

3^2.2  Test  Bed  Software  Validation. 

During  the  ATDLVT  meeting,  the  en  route  controller  team  validated 
design  changes  and  commented  on  Data  Link  functionality.  Their 
comments  and  ratings  of  the  Data  Link  designs  are  included  in  the 
following  sections. 
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3.2^3  _  Autc>inatic  Transfer  of  Communication. 

During  the  May  1990  testing^  the  ATDLVT  suggested  that  automatic 
TOC  should  be  available  for  individual  aircraft  or  for  all  aircraft 
bound  for  specific  sectors.  The  test  bed  implementation  of  the 
automatic  TOC  is  limited  and  only  allows  all  aircraft  within  a 
lector  to  be  in  automatic  or  manual  mode.  This  limitation  is  a 
result  of  the  cCmplexity  of  implementing  the  full  automatic  TOC 
design  into  the  NAS  software.  Nevertheless,  the  auto  TOC  was 
evaluated  for  its  display  attributes  and  how  it  works  in 
conjunction  with  other  NAS  functions.  The  input  action  to  enable 
or  disable  automatic  TOC  for  all  aircraft  bound  for  an  adjacent 
sector  is  as  follows:  Data  Link  Category  Function  Key  (DL  CAT 
KEY) ,  DL  SETTING  CRD  input,  T,  AUTO  Or  MAN.  This  sets  automatic 
or  manual  TOC  for  all  aircraft  in  the  sector.  The  controller  team 
evaluated  the  automatic  TOC  function,  and  focused  On  how  the 
automatic  TOC  worked  in  conjunction  with  the  current  NAS  handoff 
function. 

Four  questions  concerning  the  automatic  TOC  were  asked.  The 
questions  and  the  comments  are  provided  below. 

a.  .  What  is  your  opinion  of  the  bL  CAT  KEY,  DL  SETTING  CRD 
INPUT,  T,;  AUTO  or  MAN  input?  (See  figure  5)  . 

Controller  Comments: 


"A  lot  of  buttons.” 


From  figure  4,,  it  seems  that  a  few  controllers  would  like  to  see 
an  easier  to  remember  input  action.  The  comment  above,  "A  lot  of 
buttons,”  makes  clear  the  current  input  sequence  needs  improvement. 
During  debriefings,  the  ATDLVT  felt  that  the  Auto  TOC  inputs  should 
be  similar  to  those  used  for  Auto  Handoff. 

b.  What  is  your  opinion  of  the  TOC  inhibit  feature,  i.e., 
SECTOR  NUMBER,  1,^110?  (See  figure  6) . 

Controller  Comments: 

"Good.” 

"Worked  with  no  problem.” 

"Didn't  use.” 

"Inhibit  is  OK,  but  held  status  should  also  be  displayed  in  the 
data  block.” 

The  two  controllers  that  rated  this  function  Acceptable  with  minor 
changes  were  hew  to  the  ATDLVT  and  either  didn't  use  it  or  were 
more  concerned  with  status  in  the  FDB.  After  discussion  with  the 
team  there  was  consensus  that  the  above  inputs  were  acceptable  as 
they  are  currently  implemented. 
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CONTROLLER  RESPONSES 

6 

5 

4 

3 
2 
1 
0 

flCCEPTflBLE  MINOR  CHflNGES  MRRGINfiL  UNfiCCEPTHBLE 

FIGURE  5.  DL  SETTING,  T,  AUTO  OR  MANUAL 
CONTROLLER  RESPONSES 
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FIGURE  6.  TOG  INHIBIT  FEATURE 

c.  How  would  you  rate  the  status  display  at  the  top  of  the 
PVD?  (See  figure  7) .  What  other  symbology  would  you  suggest? 

Controller  Comments : 

"Data  Link  ON  is  good. " 

"DL  ON;  A  or  M  for  auto  or  manual  TOC." 

"None." 

Originally,  the  team  wanted  a  full  data  block  (FDB)  indication  that 
an  aircraft  was,  or  was  not,  in  automatic  TOC  mode.  After  trying 
to  implement  this  feature,  the  software  development  team  found  that 
due  to  limitations  imposed  by  the  NAS  display  system,  the  FDB 
indication  was  not  feasible.  From  figure  7,  it  is  apparent  that 
the  proposed  test  bed  displays  were  somewhat  inadequate.  During 
debriefings  the  controller  team  decided  to  display  the  Auto  TOC 
status  by  sector  in  the  computer  readout  device  (CRD) ,  similar  to 
the  CRD  Auto  Handbff  displays.  The  CRD  display  would  tell  the 
cohti oiler  which  sectors  are  currently  enabled  for  Auto  TOC. 

d.  Other  comments  and  suggestions  for  Automatic  TOC. 
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CONTROLLER: RESPONSES 
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FIGURE  7.  TOC  STATUS  DISPLAY 

"I  am  not  a  proponent  of  aiito  TOC  in  the  first  place.  It 
seems  to  work  as  advertised.  When  I  handed  off  an  aircraft  and 
used  S  with  the  handoff  in  auto  mode,  it  made  me  do  it  oyer  again. 
The  S  should  be  allowed  because  you  get  used  to  it . " 

"It  was  easy  to  get  used  to.  Changing  to  manual  mode  in 
the  middle  of  the  problem  showed  that  even  in  a  short  time  I  got 
comfortable  using  Auto  TOC.  It  seemed  to  slow  me  down  with  manual 
TOC  during  busy  periods . " 

The  controllers  were  divided  on  their  opinion  of  the  Auto  TOC 
service.  This  seems  to  be  attributed  to  the  particular  sector  the 
controller  normally  works  or  the  specific  procedures  unique  to  each 
controller's  facility.  The  two  comments  above  show  the  differing 
opinions  of  the  controllers.  It  was  agreed  that  if  the  cajpabillty 
would  be  beneficial  to  some  sectors  or  facilities,  then  it  should 
be  included,  in  the  set  of  initial  services. 

Finally  the  controllers  were  asked  to  give  an  overall  rating  of 
the  Automatic  TOCi  Figure  8  shows  these  results.  The  results 
indicate  that  overall  the  controllers  reacted  positively  to  the 
utility  of  an  Auto  TOC,  although  some  details  need  further 
improvement. 
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FIGURE  8 .  OVERALL  TOC  EVALUATION 
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3.2.4  DL/OK  With  the  S  Option  and  DL/OK  From  Anv  Sector. 

During  the  May  1990  Micro  Study,  when  Data  Link  eligibility  was 
stolen  using  the  /OK  option  with  the  S,  the  Data  Link  transaction 
was  not  displayed  in  the  status  list  of  the  sector  taking  the  /OK 
action.  The  current  test  bed  implementation  displays  the 
transaction  status  in  the  status  list  of  the  sector  taking  the  /OK 
action. 

The  controllers  were  asked  "How  would  you  rate  the  status  list 
and  Full  Data  Block  displays?”  They  all  agreed  that  the  status 
list  entry  should  be  displayed  at  the  sector  taking  the  /OK  action. 
But  the  controllers  commented  that  the  status  list  display  may  not 
be  necessary  unless  the  transaction  Failed.  This  topic  is  covered 
in  greater  detail  in  the  Data  Link  Service  Display  in  the  Status 
List  section  later  in  the  Results. 

The  controllers  were  also  asked  if  the  /OK  function  should  be 
available  for  all  sectors  who  have  had  track  control  for  an 
aircraft,  but  have  handed  that  track  control  to  another  sector. 

Controller  Comments: 

"No,  just  the  last  one." 

"No^  only  sector  working  the  aircraft." 

"No,  only  the  sector  presently  having  track  control i " 

"Should  be  able  to  /OK  Data  Link  on  an  aircraft  you  have  track 
control  of." 

"Yes ,  definitely. " 

"Yes." 


This  topic  has  been  debated  by  the  ATDLVT  for  many  meetings.  The 
"no"  responses  came  mainly  from  controllers  new  to  the  team  and  the 
test  bed.  The  "yes"  answers  are  from  the  more  experienced  ATDLVT 
members.  The  more  experienced;  members  argue  that  the  system  should 
allow  /OK  for  Data  Link  from  any  sector.  Consensus  was  reached  by 
all  members,  and  they  recommend  that  the  system  allow  the  /OK  input 
from  any  sector,  but  controller  coordination  and  Data  Link 
procedures  should  govern  how  this  Data  Link  function  works  when  it 
is  implemented  in  the  field. 

3.2.5  Held  TOC  Messages  Not  Bright. 

During  the  last  test  bed  exercise,  the  ATDLVT  decided  that  Held  TOC 
messages  should  not  be  displayed  as  double  bright  in  the  Data  Link 
status  list.  During  the  current  test,  the  controller  team 
evaluated  the  display  of  the  Held  message  without  the  double  bright 
indication.  The  controllers  were  asked  to  rate  the  display  of  Held 
TOC  messages  which  are  given  in  figure  9.  They  were  also  asked 
"Can  you  find  the  Held  TOC  message  in  the  status  list  to  uplink?" 
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FIGURE  9 i  HELD  TOC  MESSAGES  NOT  BRIGHT 

Controller  Comments:  >  " 

"Needs  to  be  double  bright  (at  least) 

"Better  than  before.:?? . 

"Yes,  maybe  we  also  need  something  in  the  data  block  »  single 
bright  TOC's  (Held)  kept  stacking  up  on  me.'? 

"No,  Normal  brightness  is  ^ine." 

"I  don't  want  the  Held  message  showing  up  the  same  as  Failed 
messages .  I  had  ho  trouble  f  inding  the  Held  messages .  ?' 

'•Yes,  but  again  this  is  time-consuming  and  diverts  the  controllers 
attention  away  from  duties." 

"T  don't  like  having  to;  look  in  the  status  list  for  HLD  TOC 
messages.  I'd  prefer  to  also  have  an  indicator  in  the  data  block.. 
The  status  list  is  tooinudh  of  a  distraction  from  my  normal  scan. 
It  takes  my  attention  away  from  other  thihgs  I  need  to  be  doing. 
It's  too  time  consuming." 

Again,  the  controllers  were  divided  on  their  opinions  of  the 
display  of  tbe  messages  in  the  status  list.  After  discussion,  the 
Controllers  agreed  that  the  Held  TOC  messages  did  not  need  to  be 
double  bright.  The  controllers  agreed  to  this  presupposing  that 
normal  (i.e..  Sent,  Delivered,  WILCO)  Data  Link  messages  would  not 
be  displayed  in  the  list,  thus  eliminating  the  clutter.  A  full 
discussion  of  normal  and  full  status  list  displays  is  covered  later 
in  the  results. 

3.2.6  Sending  Data  Link  Eligibility. 

Data  Link  eligibility  may  be  sent  to  anpther  sector.  During  the 
May  1990  tests,  the  ATDLVT  suggested  new  inputs  for  uplinking  or 
inhibiting  the  uplink  of  a  TOC  message  when  sector  eligibility  is 
sent  to  another  sector.  The  Inputs  to  send  eligibility  and  uplink 
a  TOC  message  with  the  specified  sector's  frequency  in  the  uplink 
message  is  as  follows:  DL  CAT  KEY,  Sector  Number,  .Flight 

Identification  (FLID) .  If  the  controller  chooses  not  to  uplink  a 
TOC  message  to  the  aircraft,  the  following  input  sequence  is  used: 
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DL  CAT  KEY,  Sector  Number,  I,  FLID.  The  controller  team  evaluated 
the  input  sec^ences  for  validity  and  were  in  unanimous  agreement 
that  the  input  sequence  was  good.  One  controller  felt:  that  if  the 
input  sequence  DL  CAT  KEY,  Sector  Number,  S,  ELID  were  entered,  the 
computer  should  accept  it  and  treat  it  the  same  as  DL  CAT  KEY, 
Sector  Number,  FLID..  The  other  controllers  did  not  argue  the 
point. 


3.2.7  Altitude  Timeshare . 


The  Data  Link  uplinked  altitude  and  transaction  status  bimeshare 
with  the  normal  line  2  Full  Data  Block  displays.  The  interval  of 
the  timeshare  was  set  to  6  seconds  during  the  last  micro  study  and 
was  found  to  be  unacceptable.  During  this  test,  the  controller 
team  evaluiated  the  timeshare  interval  at  1/2,  1,  1-1/2,  and  2 
seconds.  In  addition  to  the  controller  evaluation.  System  Analysis 
and  Recording  (SAR)  data  were  collected  during  the  different  time 
intervals  to  evaluate  the  impact  the  timeshare  processing  has  on 
the  Qomputer  Display  Channel  (CDC) .  These  data  were  compared  to 
a  test  run  without  Data  Link  to  determine  the  increased  workload 
on  the  CpC.  This  information  is  needed  by  the  En  Route  Software 
Development  Support  (ERSPS)  contractor  to  aid  in  the  implementation 
of  the  altitude  service. 

After  reviewing  the  altitude  timeshare  intervals,  the  controllers 
were  in  unanimous  agreement  that  the  timeshare  interval  should  be 
1-1/2  seconds. 

controller  Comments: 

’•The  1-1/2  seconds  was  best.” 

”l?-l/2  or  2  seconds." 

"1-1/2  sec  time  share  works  best*  It  doesn't  distract  the 
controller,  yet  all  the  information  is  readily  available." 
"Preferred  the  1-1/2  Second  interval  -  seemed  to  be  just  right." 
"1-1/2  second!  Most  acceptable." 

3.2.8  Full  Data  Block  Failure  Display  Options. 

in  the  May  1990  controller  evaluation,  the  entire  FDB  was  displayed 
as  double  bright  when  a  Data  Link  transaction  Failed  (i.e..  No 
Pilot  Response,  Communications  Failure,  or  Pilot  Unable) .  The 
general  consensus  was  that  this  Failure  display  method  was 
unacceptable.  The  current  test  provides  two  new  generic  FpB  failure 
indications:  (1)  the  Data  Link  eligibility  symbol  is  displayed  as 
an  oversized  character,  and  (2)  the  entire  AID  field  (i.e.,  the 
first  line  of  the  FDB)  is  displayed  as  oversized  characters. 

The  controllers  were  asked  which  alternative  they  liked  best  and 
then  asked  to  rate  that  alternative.  None  of  the  controllers  liked 
the  entire  AID  field  oversized.  They  all  picked  the  oversized 
eligibility  indicator,  but  when  asked  to  rate  this  display. 
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fi^re  id,  it  only  rated  fair  to  somewhat  good.  The  controllers 
and  technical  staff  were  both  frustrated  to  come  to  a  conclusion 
on  a  generic  failure  display  in  the  FOB.  The  controllers  haye 
agreed  in  th^  past  to  double  bright  the  status  list  enti'y  when  a 
transaction  fails,  but  they  could  not  come  to  a  consensus  for  an 
FOB  failure  indication.  It  may  be  that  the  GDC  does  not  provide 
enough  display  capability  for  this  Data  Link  option. 
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3«2.9  Menu  Text  Referent  in  the  status  List. 

The  menu  text  message  referent  and  uplinked  altitude  data  are 
displayed  in  the  Data  area  of  the  Data  Link  status  list,  Each 
controller  evaluated  whether  or  not  these  data  were  displayed 
appropriately  in  the  status  list.  The  controllers  were  in 
unanimous  agreement  that  the  menu  text  referent  in  the  status  list 
was  acceptable  as  is. 

Controller  Comments: 

"With  just  the  letter  it  is  easier  to  scan  the  list." 
"Alphanuroerics  are  acceptable." 

They  were  also  asked  "Is  the  data  sufficient?" 

"Yes. 

"Having  the  menu  text  referent  in  the  status  list  is  OK." 

"Yes." 


3.2.10  Free  Text  Recall. 

The  Free  Text  Recall  capability  was  introduced  in  the  May  1990 
Micro  Study.  This  capability  was  accepted  by  the  ATDLVT,  although 
the  input  format  was  changed  to  DL  CAT  KEY,  T,  to  recall  the 
message  in  the  CRD.  To  send  the  last  entered  message,  to  an 
aircraft  the  input  was  changed  to  DL  CAT  KEY,  T,  FLID  or  ALL. 
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When  asked  to  rate  the  input  to  recall  the  message,  once  again  the 
controllers  were  all  in  agreement  that  the  input  sequence  was 
acceptable  as  is. 

Controller  Comments: 

"Goo,d-to  have  independent  functionality  for  R  &  D.” 
i'Seemed  fair  to  easy. " 

The  controllers  were  also  asked  to  rate  the  inputs  to  uplink  the 
last  frge  text  message.  Figure  11  gives  the  controller  ratings. 
During  the  debriefing  discussions,  it  was  generally  agreed  that  the 
inputs  were  acceptable  as  is. 

The  controllers  were  also  asked  if  they  thought  the  messages  should 
be  recallable  at  both  the  R  and  D  positions .  They  all  agreed  that 
the  free  text  should  be  recallable  at  both  positions.  They  were 
also  asked  to  give  the  Free  Text  Recall  function  an  overall  rating. 
Figure  12  shows  that  free  text  recall  is  rated  as  being  somewhat 
good  and  will  saye  typing,  when  using  the  free  text  service. 
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FIGURE  11.  INPUT  TO  UP1<INK  LAST  FREE  TEXT  MESSAGE 
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FIGURE  12 .  FREE  TEXT  RECALL  OVEFALL  RATINGS 
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3.2.10,1  Data  Link  Service  Display  in  the  Status  List. 

The  Functional  Specification  for  Implementation  of  Data  Link 
Services  in  the  HCS  (reference  4)  provides  t^e  capability  to 
display,  or  not  display,  each  Data  Link  service  in  the  status  list. 
If  the  service  is  suppressed  from  display,,  normal  (i.e..  Sent,, 
beilveredv  and  WILCO)  status  will  not  be  displayed  in  the  status 
list.  However,  if  a  Data  Link  message  Fails,  the  display  of  the 
message  is  forced  in  the  status  list,  even  if  the  service  is 
suppressed  from  the  Status  list  display. 

The  controllers  were  asked  which  services  should  be  displayed. 
They  reached  agreement  that  the  status  list  should  have  two  display 
states,  default  and  full.  The  default  state  would  suppress  all 
normal  status  list  entries  for  TOC  and  altitude  assignment.  The 
purpose  of  this  state  is  to  reduce  clutter  in  the  status  list  and 
provide  only  thOse  entries  which  the  controller  needs  tO  see  in  the 
status  list.  The  default  state  will  display  all  Failures  for  all 
services.  In  addition,  the  default  state  will  display  all  free 
text  uplink  messages,  since  there  is  no  FDB  display  to  indicate 
that  a  message  has  been  uplinked.  Lastly,  the  default  state  will 
display  Held  TOC  messages.  Held  TOC  messages  are  displayed  because 
the  controllers  like  the  ability  to  slew  the  Held  status  list 
entry,  which  uplinks  the  Data  Link  TOC  message  to  the  aircraft. 

The  full  state/  selectable  through  controller  input  action,  would 
display  all  Data  Link  transactions  in  the  statue  list  regardless 
of  the  transaction's  status.  This  state  would  allow  the  controller 
to  monitor  all  transactions  via  the  status  list.  Some  controllers: 
suggested  that  all  the  Data  Link  transactions  be  contained  in  the 
status  list  despite  the  Clutter. 

Regardless  of  the  default  or  full  state  of  the  status  list,  all  the 
controllers  agreed  that  any  Data  Link  message  which  Fails  should 
displayed  as  double  bright  in  the  status  list. 

3.2.11  Communications  Backup  Downlink. 

The  Communications  Backup  Downlink  service  was  designed  by  the  en 
route  controller  team  in  the  Seattle  ATDLVT  meeting.  The  design 
was  reviewed  by  the  team  again  in  the  May  1990  Micro  Study  and 
implemented  in  the  test  bed  software.  This  section  of  the  testing 
focused  the  controller's  attention  on  the  Communications  Backup 
Downlink  service.  All  inputs  and  outputs  of  the  service  were 
exercised  and  evaluated  by  each  controller.  This  section  covers 
each  aspect  of  the  communications  backup  downlink  service. 

3 . 2 .  li .  1  D-CRD  Acknowledgement  Button  and  Alarm . 

The  controllers  were  asked  to  rate  the  alerting  mechanism  and  the 
response  to  display  the  downlink  message  on  the  D-CRD.  Figure  13 
provides  the  controller  ratings  of  the  alerting  mechanisms. 
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FIGURE  13 .  ALERTING  MECHANISMS 

Controller  Comments: 

"Have  the  D-Position  alarm  ring  with  three  bells ;  instead  of  the 
one  ding  we  currently  have." 

"Printout  should  be  when  message  is  acknowledged." 

"Alerts  are  fine,  but  when  the  bell  rings  the  controller  hits 
CRD  ACK,  which  in  this  case,  wipes  out  the  message.  This  needs 
to  be  changed  to  display  the  message  when  the  button  is  pushed." 

The  controller  ratings  and  comments  show  that  improvements  are 
needed-  with  this  section  of  the  downlink  design.  In  the 
debriefings,  the  controllers  recommended  whe  following  resolutions 
for  the  ailerts  and  responses  to  display  the  message. 

a.  The  downlink  message  is  received  by  the  Host  and  routed  to 
the  sector  with  Data  Link  eligibility.  If  there  is  a  TOC  in 
progress,  the  sector  who  last  had  Data  Link  eligibility  will 
receive  the  message. 

b.  The  D-alarm  sounds  and  the  D-CRD  acknowledgement  key  is 
lit  to  alert  the  controller  of  the  new  incoming  message. 

c.  The  controller  has  a  total  of  2  minutes  to  respond  (i.e., 
display  response)  to  the  downlink  message  (Timer  1) .  The  response 
is  generated  by  depressing  the  D-CRD  acknowledgement  key,  which, 
in  turn,  displays  the  message  in  the  D-CRD.  If  the  controller  does 
not  respond  within  the  first  l  minute,  the  D-alarm  is  sounded  again 
to  remind  the  controller  of  the  pending  downlink  message. 

d.  If  the  controller  does  not  respond  within  2  minutes,  the 
downlink  message  is  considered  to  have  timed-out.  When  this 
happens,  no  further  responses  to  the  downlink  message  are  allowed 
and  the  downlink  message  is  printed  on  the  flight  strip  printer 
(FSP) . 


Since  the  D-CRD  acknowledgement  key  is  used  for  the  dual  purpose 
of  displaying  downlink  messages  and  other  NAS  messages  at  the 
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D-CRD,  ^  the’  controllers  were  asked  "Is  the  use  of  the  D-CRD 
acknowledgement  key  to  display  downlink  messages  acceptable?  What 
if  communications  backup  downlink  message (s)  are  mixed  with  other 
messages  sent  to  the  p-ppsition?  Will  this  pose  any  potential 
jproblems?" 

Controller  Comments : 

"No  problem  once  controllers  are  used  to  it.  ZAN  gets  mixed 
messages  from  ARINC  (aircraft  downlinks)  and  amendments  from  other 
sectors  on  the  same  D-position  CRD." 

"No,  not  after  seasoning." 

"Not  as  long  as  its  printed  out  or  retained  somehow." 

"No  -  controller  input  retrieves  message." 

"Acceptable. " 

"Busy  periods  wil^l  probably  have  numerous  timeouts.” 

The  D-CRD  acknowledgement  key  was  completely  accepted  by  the 
controllers.  They  felt  downlink  messages  worked  similar  to  other 
messages  at  the  p-^position  and  were  assured  that  all  messages  would 
work  together. 

3.2.11.2  Downlink  Message  Display. 

The  controllers  were  asked  to  rate  the  display  of  the  downlink 
message  on  the  D-CRD.  Figure  14  provides  the  controller  ratings 
of  the  display. 
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FIGURE  14 .  DOWNLINK  TEXT  DISPLAY 

Controller  Comments: 

'^Downlink  message  should  work  like  other  D-GRD  acknowledgements. 
"Message  shouldn't  be  displayed  until  after  CRD-ACK  button  is 
pushed . " 

"Message  number  looks  like  an  aircraft  CID.” 


CONTROLLER  RESPONSES 
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3 . 2,11. 3  Flight  Strip  Printer  Data  Display . 

As  part  of  the  coimiunications  backup  downlink  service,  the  ability 
to  print  the  downlink  message  on  the  FSP  was  cited  as  a  requirement 
by  the  ATDLW.  They  felt  that  a  hard  copy  of  the  downlink  message 
was  needed  for  future  reference  or  as  a  backup  in  case  the  downlink 
message  was  inadvertently  erased  from  the  D-CRD.  The  controllers 
were  asked  to  rate  the  FSP  output  (figure  16). 
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FIGURE  16.  FLIGHT  STRIP  PRINTER  OUTPUT 
Controller  Comments: 

••Put  CID  in  red  on  comer  of  strip. •• 

••Need  to  have  ah  input  to  force  message  to  printer.  Should  only 
be  a:utomatic  on  timeout.  •• 

••Would  prefer  no  output  except  when  D-side  GRD  does  not  work 
properly.  •• '. 

••CID  in  red  in  lower  left  of  strip.  No  three  digit  message  ID. 

The  contmllers  were  also  asked  the  following  questions.  Is  the 
data  displayed  in  the  proper  field  of  the  FSP?  If  not,  which  dhta 
should  be  displayed  in  which  fields  of  the  FSP  output? 

Controller  Comments: 

••OK.  •• 

••Did  not  see  one.” 

••ClD  on  strip.  •• 

••Data  Link  qualifier  needs  to  be  developed  and  displayed.  '• 
••Pr#>ably.^^ 

••Red  CID'  lower  left  of  strip. •• 

Will  the  flight  strip  printout  be  required  as  soon  as  the  downlink 
message  is  received? 
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Controller  Coniinents: 


"No.” 

"I  think  the  D-side  should  answer  CRD  and  receive  message  then 
t4ke  action  on  the  message.  Printing  of  message  does  not  seem 
necessary." 

"As  soon  as  it  is  acknowledged  at  D-position." 

"No  -  should  be  forced  by  controller." 

"Np." 

"No  -  when  message  is  acknowledged 

Do  all  downlink  message  need  to  be  printed  out  on  the  FSP? 


Controller  Copnents: 


"Not  as  long  as  the  message 
until  the  CRD-ACK  button  is 
"No." 

"Yes  or  retained  for  recall 
"No." 

"No." 

^'Yes,  as  a  backup  if  one  is 


doesn't  show  up  in  the  D-ppsition  CRD 
pushed . " 

somehow^ " 


inadvertently  removed  from  the  CRDi" 


The  cpntrPllers  were  npt  satisfied  with  the  timing  of  the  printout 
or  the  format  of  the  printout.  They  recommended  using  the  same 
format  for  the  downlink  message  as  is  currently  used  for  an 
altitude  update  message  received  at  the  D-ppsition.  Additionally, 
they  decided  to  print  the  entire  message  iri  red..  The  dontrPllers 
also  recommended  to  optionally  (set  in  adaptation)  print  ’  the 
dpwnlink  message  when  the  p-CRD  acknowledgement  key  is  depressed 
tP  display  the  message.  Also,  if  the  downlink  message  times-out, 
the  downlink  message  is  printed. 


3.2.11.4  -Acknowledgement  of  the  Downlink  Message. 

After  the  downlink  message  is  displayed  in  the  p-CRD, the  controller 
has  one  minute, to  read  and  respond  to  the  message.  The  input  for 
this  action  is;  6ther  MSGS  QAK,,  CZ,  MESSAGE  NUMBER,  Optional 
Response  (S  -  Standby,  A  -  Approved,  R  -  Roger,  W  -  Wiled,  U  - 
Unable) ,  FLID.  If  the  optional  response  is  omitted,  a  default 
response  of  Roger  is  used  as  the  response  to  the  pilot.  The 
controller  ratings  of  the  inputs  are  given  in  figure  17. 

The  controllers  discussed  the  possibility  of  making  the  input 
format  shorter,  but  could  not  come  to  a  conclusion  on  what  the 
input  should  be.  They  prefer  a  D-QAK  which  would  take  the  place 
of  the  fii^st  two  inputs  above,  but  each  center  adapts  the.  D-QAKs 
slightly  different.  Also,  with  each  center's  adaptation:  of  D-QAKs, 
thdre  Usually  aren't  any  spare  QAKs.  The  team  decided  that  if  the 
center  felt  a  D-qAK  for  communications  backup  downlink  was  needed 
over  another  QAK,  then  it  could  be  adapted  per  site.  Otherwise, 
the  above  input  sequence  holds. 
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FIGURE  17..  ACKNOWLEDGEMENT  INPUT  FORMAT 

The  controllers  were  also  asked  "Does  the  controller  have  to 
respond  to  a  cominunicatlons  backup  downlink  message?" 

Controller  Comments: 

"No,  only  if  the  nature  of  the  message  requires  a  response." 

'•No  -  system  should  send  a  standby." 

"At  least  a  standby.?' 

"CRD  ACK  -r  should  be  sufficient  -  generate  a  Roger," 

?'Time  may  not  permit  a  response." 

The  controllers  were  then  asked  "What  should  the  default  response 
to  the  downlink  message  be?  Should  there  be  additional  allowable 
values  for  the  response?" 

Controller \ Comments : 

"Message  received  and  acknowledged  (i.e.,  Roger). 

?' Stand-by," 

"Standby  default. 

"Roger. " 

"Standby." 

It  was  unclear  from  the  controller  comments  and  debriefings 
whether  or  not  a  response  will  be  required.  Also  the  type  of 
default  response  was  not  clear,  Roger  will  be  the  default  at 
present.  Further  testing  with  pilot  involvement  is  needed  to 
resolve  this  issue. 

The  controllers  were  aske<^  for  their  overall  evaluation  of  the 
communications  backup  downlink  service.  Their  ratings  are  given 
in  figure  18 .  The  overall  opinion  of  the  ATDLVT  ranged  from  fair 
to  sl^ightiy  good.  The  controllers  stated  in  the  debriefings  that 
they  felt  with  the  improvements  stated  in  the  results,  '  the 
communications  backup  downlink  service  would  be  beneficial  to  the 
ATC  system. 


1  I  ■ 
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FIGURE  18.  COMMUNICATIONS  BACKUP  OVERALL  RATING 

This  was  the  first  attempt  at  the  communications  backup  downlink 
service.  Many  problems  were  identified  and  some  solutions  were 
reached.  Further  testing  is  needed  in  this  area,  especially  with 
ihyolyement  from  pilot  groups.  Finally,  a  logic  flow  chart,  figure 
19,  shows  the  steps  involved  in  the  communications  backup  downlink 
design.  This  chart  shows  the  sequence  of  events  and  resultant 
outputs  that  occur  after  a  downlink  message  has  been  received  by 
the  Host  computer, 

3.2.12  D-^Position. 

In  past  ATDLVT  meetings,  the  D-cohtroller  position  has  been  cited 
as  a  potential  candidate  for  performing  a  subset  of  the  Data  Link 
functions*  in  previous  en  route  D'ata  Link  tests'  at  the '  FAA 
Technical  Center,  the  D-position  has  not  been  included  as  part  of 
the  evaluations.  As  a  result  of  the  current  downlink  design  and 
the  potential  benefits  of  the  D-position  used  in  conjunction  with 
Data  Link,  the  use  of  the  D-position  was  included  in  the  November 
1990  test.  The  purpose  of  the  test  was  to  solicit  ideas  from  the 
ATDLVT  about  the  use  of  the  D-position.  Functions  and 
responsibilities  of  the  D-position  and  the  potential  workload 
reduction  on  the  R-positiOn  were  the  focus  of  this  effort. 

A  starting  point  for  the  test  was  to  define  which  Data  Link  functions 
the  D-positioh  could  perform.  The  controllers  were  asked  "Comment  on 
the  Data  Link  functions  that  can  be  performed  at  the  D-position." 

Controller  Comments: 

"Should  be  able  to  do  free  text  and  backup  comm,  TOC." 

"Assigned  altitude,  interim  altitude,  free  text,  handoff,  and  TOC. 
Once  inputs  have  been  learned  to  do  the  above  functions,  the  D-side 
can  uplink  as  quickly  as  the  R-side." 

"D  position  is  very  necessary.  It  will  increase  Safety  and  help  out 
the  R-^controlier.  It  reduces  frequency  congestion." 

"Delete  messages  from  the  status  list  -  needs  to  be  included  as  a 
p-side  function." 
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FIGURE  19.  DOWNLINK- LOGIC  FLOW 

From  the  comments  and  debriefings,  the  controllers  felt  that  free 
text,  backup  communications,  ahd  handoffs/TOC  would  be  the  most 
iikeiy  candidates  for  D-position  responsibility.  Also  cited  as 
potential  responsibilities  were  status  list  maintenance,  monitoring 
for  Data  Link  failures,  and  possibly  assigned  and  interim  altitudes, 
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although  the  controllers  felt  that  close  coordination  between  the  R- 
and  D-positipris  would  have  to  exist  for  altitude  assignments. 

Next,  the  controllers  were  asked  to  "Commerit  on  how  future  Data  Link 
testing  could  be  conducted  to  help  answer  the  questions  of  increasing, 
a  sector's  efficiency  and  reducing  workload  on  the  R-position." 

Controller  Comments: 

"Problems  need  to  be  developed-  which  will  completely  saturate  the 
R-controIler  and  force  the  D-side  to  track  from  the  manual  position. 
This  would  indicate  whether  a  busy  sector  could  be  worked  mainly  by 
Data  Link  and  working  relationship  needed  from  the  R  and  D  sides  when 
utilizing  Data  Link." 

"Run  the  D-position  just  like  we  did  Until  we  figure  out  the  problems. 
We  may  have  to  lock  out  certain  functions  if  there  are  conflicts 
between,  the  R  and  D- sides." 

"D-side  has  to  be  included  on  future  tests  and  controllers  need  to 
be  thoroughly  familiar  with  the  lab  operation.  (Proper  sectors  for 
coordination,  etc) .  p-controller  then  needs  to  work  with  R-controller 
in  order' to  Use  the  TOC  function." 

The  controllers  expressed  the  concern  that  the  subject  controllers 
in  future  tests  should  be  thoroughly  familiar  with  the  test  bed 
airspace  and-  any  other  items  which  are  unique  to  the  best  bed. 
Sufficient  training  time  will  be  required  if  sector  efficiency  is  to 
be  measured.  Also,  the  controllers  felt  that  high  workload  scenarios 
need  to  be  developed  to  test  the  efficiency  of  a  sector.  Future 
testing  using  the  en  route  Data  Link  test  bed  will  need  to  be 
carefully  planned  to  obtain  valid  results  .for  measuring  the  increased 
sector  efficiency  using  Data  Link.  From  the  ATDLVT  input,  high- volume 
scenarios  and  controller  training  will  play  an  important  part  of  the 
test  design. 

3.2. 13  Data  Link  Procedures . 

The  development  and  testing  of  the  initial  Data  Link  sen^ices  and 
functions,  to  date,  have  not  involved  any  substantival  discussion  on 
Data  Link  air  traffic  control  (ATC)  procedures  based  on  ATC  7rio.65 
manual.  The  discussion  of  the  Data  Link  ATC  procedures  was  intended 
to  simulated  discussion  on  the  subject  and  document  procedures  for 
testing  purposes.  The  ATDlvt  provided  procedural  guidelines  to  issues 
pertaining  to  sending  messages  to  aircraft,  failed  messages,  pilot 
check-in,  and  pilot  responses  to  Data  Link  ATC  message. 

The  discussion  on  rules  for  sending  Data  Link  messages  to  aircraft 
resulted  in  several  procedures: 

a.  A  controller  may  send  Data  Link  messages  to  more  than  one 
aircraft  simultaneously. 
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b.  A  controller  nay  send  a  message  of  the  same  service  type  to 
more  than  one  aircraft  simultaneously. 

c.  A  controller  nay  send  only  one  message  per  service  type  to  a 
single  aircraft. 

‘  d.  A  controller  may  not  send  messages  of  the  same  service  type 
to  a  single  aircraft  while  a  message  of  that  sei^lce  type  Is 
outstanding  for  that  aircraft  with  the  exception  of  a  free  text 
message. 

,The  Issue  of  how  a  controller  resolve  a  Failed  Data  Link  message 
resulted  In  the  following  procedure: 

a.  If  a  Data  Link  message  falls,  use  the  radio  or  resend  the 
message  at  the  controller's  discretion. 

b.  If  the  use  of  the  radio  is  required,  the  controller 
phraseology  will  be  at  the  controller's  discretion. 

The  Issue  as  to  whether  the  pilot  will  be  required  to  check-in  with 
a  controller  upon  switching  to  a  new  sector  frequency  resulted  in  the 
ATDLVT  agreeing  that  the  current  check-in  procedure  mUst  be  adhered 
to,  but  the  method  (voice  or  Data  Link)  by  which  this  will  be 
accomplished  will,  be  discussed  in  a  future  meeting. 

The  discussion  on  what  the  pilot  is  expected  to  do  if  he/ she  responds 
with  an  Unable  response  resulted  in  the  following  procedure:  The  pilot 
must  use  voice  to  inform;  the  controller  as  to  why  he/ she  cannot  comply 
with  the  Data  Link  ATC  instruction^ 

The  ATDLVT  also  agreed  that  the  pilot  will  be  expected  to  respond  to 
Data  Link  ATC  instructions  with  a  WILCO  response.  This  issues  must 
also  be  discussed  with  the  pilot  Data  Link  team. 

The  Data  Link  procedural  issues  discussed  during  the  meeting  are  by 
no  means  conclusive  and;  is  only  the  beginning;  of  issues  that  must  be 
discussed  and  resolved  by  both  the  controller  and  pilot  Data  Link 
teams . 

2.2  ALTITUDE  TIMESHARE  DISPLAY :  SYSTEM  IMPACT. 

The  test  bed  software  provided  timeshared  display  information  during 
ah  Altitude  Assignment  transaction.  To  concurrently  display  both  an 
uprinked  altitude  and  the  current  altitude,  the  FDB  altitude  field 
(line  2)  timeshared  the  displayed-altitude  and  conformance  symbol, 
with  the  uplinked-altitude  and  transaction  status.  The  test  bed  Host 
computer  generated  the  display  timeshare  by  sending  a  new  data  block 
(Host  to  CDC  Write  Over  message)  each  time  the  display  alternated. 
These  messages,  which  occurred  only  for  data  blocks  executing  an 
Altitude  Assignment  transaction,  added  to  the  messages  normally  sent 
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for  sector  displays.  The  addition  of  the  timeshare  display  for  Data 
Link  Altitude  Assignments  represented  an  additional  quantity  of  FDB 
Write  Over  messages  for  those  tracks  executing  an  Altitude  Assignment 
transaction. 

To  investigate  the  system  impact  of  the  timeshare,  data  from  two 
comparable  test  runs  were  collected.  The  tests  are  identified  as  run 
#4;  11/6/90  (Timeshare  alternation^!. 5  seconds)  (SAR=  AC2130) ,  and  run 
#4;  11/7/90  (Baseline)  (SAR=  AC2134) .  Clock  time  for  both  sets  of 
data  is  145900-152000. 

3.3.1  Analysis. 

For  each  sector,  the  total  quantity  of  Write  Over  messages  from  the 
baseline  run  was  compared  with  that  from  the  Data  Link  run.  The 
heavier  traffic  sample  was  used  for  both  runs.  For  the  analysis, 
increases  in  Write  Over  messages  were  assumed  to  result  from  the  use 
of  the  Data  Link  Altitude  Assignment  function. 

The  two  sets  of  data  were  collected  on  two  different  evenings,  using 
the  same  scenario,  but  with  differences  in  the  operational  tests. 
Controllers  operating  the  positions  had  switched;  R/D;  sides  so  that 
different  personnel  made  operational  control  decisions,  and  the 
operation  at  the  ghost  sector  was  modified  in  that  more  aircraft  were 
.accepted  by  an  operating  sector  during  the  Baseline  run  than  during 
the  Data  Link  run. 

The  collected  data  included  the  total  number  of  ’’flights  handled”  for 
each  sector.  Differences  in  flight  distribution  among  sectors 
suggested  that  the  operational  characteristics  of  the  two  test  runs 
varied  and  precluded  detailed  comparisons,  on  the  other  hand,  the  use 
of  a  common  traffic  sample  and  standard  operational  procedures  for 
test  conduct  justified  an  overall  comparison  of  Write  Over  message 
quantities. 

3.3.2  System  Impact . 

Quantities  of  Write  Over  messages  were  compared  to  derive  percentage 
changes  between  Baseline  and  Data  Link  test  runs.  The  percentage 
changes  of  Write  Over  messages  between  the  two  data  sets  exhibited  no 
significant  statistical  variation.  The  results  suggest  that  ho  Data 
Link  activity  persisted  long  enough  to  result  in  significant  increases 
of  Write  Over  message  generation. 

In  consideration  of  the  Host/Data  Link  operational  implementation  time 
frame,  it  can  be  expected  that  multiple  Altitude  Assignments  at  one 
sector  will  not  be  performed.  Further,  pilot  responses  will  occur 
within  a  40-second  time  frame.  Since  the  timeshare  display  will  be 
used  only  occasionally,  the  increased  data  block  message  quantity  will 
not  significantly  affect  system  throughput. 
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since  the  test  results  are  based  on  a  small  data  sample,  and  represent 
a  quick  look  at  the  total  accumulated  Write  Over  message  quantities, 
detailed  analysis  of  display  channel  system  impact  was  not  warranted. 
Detailed  interface  analysis  with  real  system  data  should  be  performed 
to  generate  peak  display  loads,  and  tb  assess  the  System  impact. 
Display  channel  processing  delays,  if  they  occur,  could  increase  the 
time  or  stability  of  the  display  alternation.  Visual  verification 
that  the  display  will,  maintain  the  1.5  second  timeshare  interval 
during  periods  of  reasonably  heavy  display  data  transmission  should 
be  performed. 

3.4  SYSTEM  DATA. 

NSSF  Target  Generation  Programs  performed  the  basic  aircraft 
simulation  functions  which  included  target  initialization,  target 
update,  navigation,  holding,  approach  simulation,  simulator  pilot 
processing,  radar  processing,  and  data  collection. 

Data  reduction  and  analysis  routines  provided  a  means  of  extracting 
and  analyzing  the  data  measures  related  to  the  concept  under  study. 
The  reports  provided  such  data  as:  lists  of  all  violations  of  ATC 
separation  standards  including  the  position  and  motion  characteristics 
of  each  aircraft  at  the  start  and  end  of  the  violation,  duration  of 
the  violation,  the  horizontal  and  vertical  separation  of  the  closest 
point  bif  approach,  and  a  categorization  of  instructions  (e.g.,  speed 
commands  and  vectors)  issued  to  each  aircraft. 

The  purpose  of  develbping  an  initial  set  of  performance  measures  was 
to  determine  the  quality  of  measurement  of  system  performance  and 
statistical  treatment  that  is  possible  and  appropriate  for  assessing 
■future  simulations  of  Data  Link  services.  It  was  not  intended  that 
they  be  used  for  a  comparative  evaluatibn  of  voice  and  Data  Link  in 
the  present  study.  The  major  purpose  of  the  present  study  was  to 
obtain  design  information  through  controller  feedback  and  was, 
therefore,  not  planned  for  the  statistical  treatment  of  the 
performance  data. 

The  key  NSSF  performance  measures  that  were  collected  for  each  run 
in  this  study  included  the  following; 

The  number  of  aircraft  handled  for  each  sector. 

The  duration  (in  seconds)  of  aircraft  handled. 

The  number  bf  conflicts  within  each  sector. 

The  duration  (in  seconds)  of  each  conflict. 

The  number  of  between  sector  conflicts. 

The  duration  (in  seconds)  of  each  conflict  between  sectors. 

The  maximum  Aircraft  Proximity  Index  (API).  The  purpose  of  this  index 
is  to  provide  a  number  that  indicates  the  danger  or  seriousness  of  a 
.  confliction  between  two  aircraft.  It  is  based  on  the  smallest 
vertical  and  horizontal  separation  during  which  a  conflict  existed. 
It  is  not  based  on  the  slant  range  miss  distance. 
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The  Closest  Point  Of  Approach  (CPA) .  This  measure  is  based  on  slant 
range  miss  distance. 

The:  CPA  less  than  a  thousand  feet. 

The  CPA  less  than  300  hundred  feet. 

The  hunger  of  path  changes. 

The  average  separation  distance  (in  miles) . 

The  standard  deviation  of  separation  distance. 

The  average  time  in  sector  (in^  seconds) . 

The  standard  deviation  of  time  in  sector. 

The  number  of  cancellations. 

The  number  of  completed  flights. 

The  nui^er  of  pilot  messages. 

3.5  EN  ROUTE-TERMINAL  JOINT  AIRSPACE  DISCUSSION. 

During  the  initial  ATDLVT  evaluations  of  en  route-terminal  Data  Link, 
numerous  airspace  deficiencies  where  noted.  In  an  attempt  to  make 
Data  Link  simulation  as  realistic  as  possible,  the  controller  team  set 
forth  to  develop  requirements  for  joint  en  route-terminal  end-to-end 
testing.  This  new  test  bed  adaptation  must  be  able  to  interface 
between  the  en  route-terminal  test  beds  and  have  real  time  flight 
simulators  interfaced  fOr  aircrew  Data  Link  evaluation  and  realism. 

The  ATDLVT  controllers  defined  the  following  airspace  requirements 
as~a  minimum  for  a  realistic  end’^to-4nd  test  bed. 

a.  En  route  facility,  preferable  Washington  Center. 

b.  Terminal  ARTS  IIIA  at  least  level  4  or  higheri 

c.  Multiple  approaches  (parallel  and  intersecting) . 

d.  Satellite  airports . 

e.  Four-corner  post  operation. 

f .  Four  to  five-sector  operation. 

g.  Flight  Plans  consisting  of  arrivals,  departures,  and 
overflights  for  both  the  en  route/ terminal  options. 

4.-^  CONCLUSIONS. 

Conclusions  derived  from  the  results  of  the  testing  and  debriefings 
presented  in  this  report  are  provided  below.  Based  on  these 
conclusions,  section  5  identifies  recommendations  for  future  testing 
as  well  as  for  additional  functional  development  Of  the  Data  Link  air 
traffic  control  (ATC)  services  identified  herein. 

4.1  TEST  BED  ACTIVITIES. 

Controllers  agreed  that  the  test  bed  application  of  Washington  Air 
Route  Traffic  Control  Center  (ARTCC)  airspace  provided  a  realistic 
operational  problem.  As  a  result  of  the  operational  complexity 
associated  with  the  realism,  a  longer  controller  training  period  would 
have  been  desirable.  In  addition,  controllers  indicated  that  the  test 
scenarios  should  be  enhanced  as  follows: 
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a.  A  percentage  of  hon-Data  Link  aircraft  should  be  included. 

b.  Airspace  in  future  testing  should  include  airports  and 
associated  feeder  sectors.  In-trail  spacing  should  be  included  as 
part  of  sector  operations. 

It  was  also  concluded  that  Data  Link  operations  for  aircraft 
transitioning  between  facilities  need  to  be  investigated.  Associated 
test  bed  requirements,  scenarios,  procedures  and  software  functional 
requirements  need  to  be  developed  for  Transfer  of  Communications  (TOC) 
between  en  rbute  and  terminal  facilities. 

4 . 2  VOICE  CHECK-IN/IN-ITIAL  CONTACT .  ■ 

Controllers  identified  pilot  voice  check-in  as  a  significant, 
unresolved  issue.  The  current  TOC  design  includes  no  software 
mechanism  for  verifying  a  currently  assigned  altitude. 

However,  the  participating  controllers  felt  that  voice  check-in  could 
be  phased  out,  thus  achieving  the  voiceless  TOC,  as  controllers  and 
pilots  acquire  Data  Link  field  experience. 

4.3  AUTOMATIC  TRANSFER  OF  COMMUNICATIONS. 

The  controller  opinion  of  the  automatic  TOC  service  was  divided.  Some 
controllers  said  that  they  wOiild  prefer  to  use  the  capability;  others 
would  hot. 

■The  tested  automatic  TOC  is  usable,  although  some  details  need  further 
development.  The  input  to  establish  the  auto/manual  setting  for  TOC 
-was  found  to  be  complex.  Controllers  indicated  that  the  automatic 
TOC  inputs  should  be  similar  to  those  used  for  automatic  Handof f . 

The  inputs  to  use  the  inhibit  feature  were  found  to  be  acceptable  as 
they  are  currently  implemented. 

4.4  SECTOR  DATA  LINK  DISPLAYS. 

4.4.1  Plan  View  Display  rpvb)  Information. 

The  tested  Full  Data  Block  (FDB)  displays  for  alerting  to  a  Data  Link 
transaction  failure  state  were  found  to  be  unacceptable  by  the 
controllers.  Although  the  oversized  Data  Link  eligibility  indicator 
was  preferred  over  other  techniques,  no  acceptable  method  that  is 
technically  feasible  was  identified. 

The  PVD  header  display,  showing  Data  Link  settings,  should  be  changed 
to  provide  easy  comprehension  and  reduce  clutter.  The  ON/OFF 
indicator  for  Data  Link  system  processing  should  be  continuously 
displayed,  while  other  setting  information  should  be  available  upon 
request. 
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Held  TOC  messages  need  not  be  double  bright,  if  the  other  states 
(Held,  Sent,  Delivered,  WILCO)  are  not  displayed. 

The  status  list  should  have  two  display  states:  Full  and  Default.  The 
Fuii  state  would  display  all  Data  Dink  transactions  in  the  status  list 
regardless  of  the  transaction's  status.  The  Default  state  would 
suppress  all  normal  status  list  entries  for  TOC  and  altitude 
assignment,  display  all  failures  for  all  services,  display  ail 
CoBununications  Backup  uplink  message  transactions,  and  display  Held 
TOC  messages . 

Any  Fail  transactions,  regardless  of  Default  or  Full  status  list 
operation,  should  be  displayed  as  double  bright  in  the  status  list. 


4.4.2  Computer  Readout  Display  rCRD^  Information. 

The  automatic  TOC  status  by  sector  should  be  indicated  in  the  CRD  in 
a  manner  similar  to  the  CRD  automatic  Handoff  displays. 

The  CRD  display  should  indicate  the  sectors  that  are  currently  enabled 
for  automatic  TOC. 

1.5  DATA  LINK  ELIGIBILITY. 

The  tested  message  format  for  sending  eligibility  and 
sending/ inhibiting  an  uplink  is  satisfactory.  Also,  the  use  of  "/Ok” 
to  acquire  Data  Link  eligibility  should  be  allowed  from  any  sector. 

4 . 6  ALTITUDE  TIMESHARE .  . 

The  preferred  alternation  display  interval  for  timesharing  the 
uplinked  altitude  with  the  normally  displayed  altitude  in  the  FDB  is 
1.5-seconds . 

Summary  counts  of  Host  data  blocks  suggest  that  using  the  Write  Over 
message  to  generate  a  display  timeshare  for  altitude  assignment 
transactions  will  not  significantly  affect  the  display  channel 
interface  in  the  near  term. 

Only  four  sectors  were  used  and  percentages  were  derived  from  a  small 
data  sample.  More  extensive  and  detailed  testing  is  needed  to  assess 
the  display  timeshare 's  impact  on  the  display  channel  processing. 

4.7  MENU  TEXT  REFERENT  IN  THE  STATUS  LIST. 

The  menu  text  referent  in  the  status  list  is  acceptable  as  tested. 
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4i.8  FRBE  TEXT^I^CALt. 

The  input  message  to  recall  the  previously  used  free  text  is 
acceptable  as  tested.  The  recall  capability  should  be  provided 
independently  at  both  the  R-  and  D-c6ntroller  positions. 

4.9  COMMUNICATIONS  BACKUP  DOWNLINK. 

The  controllers  stated  that,  with  the  recommended  improvements, 
(section  3.2.11)  the  Communications  Backup  Downlink  service  will 
benefit  the  ATC  system  by  providing  additional  means  of  air/ground 
communications. 

The  controllers  indicated  that  the  tested  Communications  Backup 
Downlink  messages  contained  sufficient  and  necessary  data. 

The  D-CRD  Acknowledgement  key  was  found  to  be  suitable  for  controller 
use  with  downlink  messages.  The  controller  ratings  and  comments 
indicate  that,  for  the  D-CRD  acknowledgement  section  of  the  design, 
two  response  time  parameters  are  necessary.  The  controller  should 
have  2  minutes  to  respond  to  the  downlink  message,  by  pressing  the  CRD 
Acknowledge  key.  If  the  controller  does  not  respond  within  1  minute, 
the  audible  alarm  is  .again  sounded  to  alert  to  the  pending  message. 
After  the  2  minutes  have  expired,  no  response  to  the  pending  message 
should  be  allowed  and  the  message  should  be  printed  on  the  flight 
strip  printer  (FSP) . 

Communications  Backup  Downlink  messages  should  be  referenced  by  use 
of  a  two-digit  number. 

The  computer  identification  number  (CID)  for  the  aircraft  should  be 
added  to  the  downlinked  message  display  on  the  CRD. 

The  controllers  recommended  using  the  same  format  for  the  downlink 
message  display  as  currently  used  for  altitude  update  messages 
displayed  at  the  D-position. 

The  received  message  should  always  be  printed  on  the  FSP.  The  format 
Of  the  printout  should  be  refined  to  include  a  Data  Link  equipment 
qualifier  (when  it  becomes  implemented)  and  red  printing  for  the  CID. 

The  FSP  output  of  the  received  message  should  occur  either  when  the 
message  is  acknowledged  or  displayed  at  the  D-position  by  the 
controller,  or  when  the  message  times  out  with  no  acknowledgement. 

The  input  action  to  respond  to  a  received  Communications  Backup 
bownlink  message,  when  implemented,  should  require  fewer  keystrokes 
than  the  tested  input  action.  A  D-Gontroller  Quick  Action  Key  would 
be  preferred  over  the  two-character  message  type  input.  (If  was 
recognized  that  spare  QAKs  are  probably  not  available  at  field 
facilities. ) 
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When  the  D-controller  enters  a  message  to  respond  to  the  received 
message,  the  default  should  be  set  to  either  ''ROGER”  or  "STANDBY.” 
Further  testing  with  pilot  involvement  is  necessary  to  identify  and 
resolve  this  and  other  issues  regarding  the  use  of  the  Communications 
Backup  Downlink  service. 

4.10  D-POSITION  OPERATIONS. 

Communications  backup  and  handoff/TOC  are  the  most  likely  candidates 
for  p-controller  responsibility.  The  controllers  also  suggested  that 
the  p-controlier  could  perform  Status  list  maintenance  and  monitor  for 
Data  Link  failures.  D-controller  inputs  to  enter  Assigned  and  Interim 
altitude  actions  were  considered  as  possibilities,  but  require  further 
analysis  and  testing. 

4.11  FUTURE  TESTING  FOR  WORKLOAD  REDUCTION. 

New  test  scenarios,  developed  to  saturate  the  R-controller,  are 
necessary  to  force  operational  impact  at  the  D-controller.  To 
successfully  conduct  a  test  with  high  workloads,  controller 
familiarity  is  essential.  Sufficient  hands-on  training  periods  will 
be  necessary  to  enable  test  controllers  to  become  completely  familiar 
with  the  test  bed  airspace  and  any  other  items  unique  to  the  test  bed. 

4.12  DATA  LINK  PROCEDURES. 

Discussions  oh  rules  for  Data  Link  message  transmissions  resulted  in 
several  recommended  procedures  related  to  multiple  uplinks,  resolving 
failed  transactions,  and  pilot  check-in. 

The  procedures  discussion  was  not  conclusive,  but  identified  a  need 
for  both  controllers'  and  pilots'  participation  in  the  development 
of  procedures  and  the  resolution  of  issues. 

5.  RECOMMENDATIONS. 

Listed  below  are  the  recommendations  for  future  efforts  under  the 
Federal  Aviation  Administration  ,  (FAA)  Data  Link  program.  These 
recommendations  are  derived  from  the  findings  and  conclusions  stated 
herein . 

5 . 1  TEST  BED  ACTIVITIES . 

The  Washington  Air  Route  Traffic  Control  Center  (ARTCC)  adaptation, 
should  continue  to  be  used  in  the  en  route  Data  Link  test  bed.  A  Data 
Link  test  bed  capable  of  interfacing  computer  systems  from  separate 
facilities  should  be  established.  Associated  test  bed  technical 
requirements,  scenarios,  procedures,  and  software  need  to  be  developed 
to  exercise  Data  Link  functions  for  transitioning  aircraft. 
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The  airspace  should  Include  airports  and  feeder  sectors.  In-trall 
spacing  should  be  Included  as  part  of  the  test  conduct  requirements. 

A  percentage  of  non-Data  Link  equipped  aircraft  should  be  Included. 

5.2  VOICE  CHECK-IN/INITIAL  CONTACT. 

An  Initial  contact  procedure  to  provide  a  voiceless  transffe^-  of 
communication  (TOC)  should  be  developed.  Discussions  and  testing 
with  pilots  and  controllers  should  be  conducted  to  address  the  Issue 
of  voice  check-in,  and  to  define  associated;  operational  requirements. 

5.3y-AUTO^TIC  TRANSFER  OF  COMMUNICATIONS. 

An  automatic  TOC  function  should  be  implemented  for  future  test  bed 
activities,  and  should  be  Incorporated  In  en  route  software  to  be 
subjected  to  operational  test  and  evaluation.  Use  of  the  function 
should  be  optional  at  each  sector  position.  Further,  sector  Inputs 
to  select  the  option  should  be  similar  to  those  used  for  selecting 
automatic  HandOff. 

5.4  ■  DATA  LINK^FAILURE  DISPLAYS. 

A  generic  display  technique  for  alerting  to  transaction  failures 
should  be  developed  and  tested. 

.  5 . 5  ITEMS  FOR  OPERATIONAL  TEST  AND  EVALUATION  OT&E) . 

En  route  software  that  will  incorporate  Data  Link  air  traffic  control 
(ATC)  services  should  Include  the  items  listed  below,  which  should  be 
subjected  to  OT&E. 

a.  The  optional  automatic  TOC  (sections  4.33  and  4.4. 2). 

b .  The  TOC  Inhibit  feature  ( section  4.3). 

c.  The  detailed  modifications  to  PVD  and  CRD  displays  identified 
herein  (section  4.4) . 

d.  The  tested  message  formats  and  use  of  "/OK"  for  establishing 
Data  Link  eligibility  (section  4.5). 

e.  The  altitude  timeshare  display  capability,  with  display 
interval  set  to  1.5-seconds  (section  4.6). 

f .  The  tested  use  of  the  menu  text  referent  in  the  status  list 
(section  4.7) . 

g.  The  tested  input  message  to  recall  previously  used  free  text 
(section  4.8) . 
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5.6  COMMUNICATIONS  BACKUP  DOWNLINK. 

The  functional  design;  and  use  of  the  Communications  Backup  downlink 
should  be  pursued  in  accordance  with  the  detailed  modifications  to 
the  design  identified  herein  (section  4.9) .  Further,  pilots  and 
controllers  should  participate  in  developing  the  default  response 
messages  and  in  developing  procedures  associated  with  the  function. 

5.7  FUTURE  TESTING. 

Recommendations  for  future  Data  Link  testing  are  contained  in  the 
following  subsections. 

5.7.1  Training  Requirements. 

Testing  in  the  future  will  involve  heavy  workload  scenarios,  as  well 
as  in-trail  spacing  requirements.  Since  participating  controllers 
will  require  extensive  training  and  hands  on  time,  test  facility 
scheduling  and  test  planning  should  increase  training  times  beyond 
that  assigned  in  the  past. 

5.7.2  D-Position  Responsibilities. 

Further  testing  should  be  conducted  to  develop  the  D-position 
capability  in  connection  with  Data  Link.  In  support  of  that 
requirement,  D-positioh  operational  responsibilities  should  be 
identified  and  tested,  and  new  traffic  scenarios  should  be  developed 
to  increase  sector  workloads. 

5.7.3  Altitude  Timeshare  Display  Impact., 

Additional  testing  should  be  conducted  to  assess  the  effects  of  the 
Altitude  Timeshare.  A  large  scale  test  built  from  real  operational 
data  and  run  from  simulation  tapes  should  be  assembled.  The  display 
channel  should  be  tested  to  verify  that  the  1.5  second  alternation  is 
maintained  during  peak  heavy  loads. 

5.7.4  Data  Link  Procedures. 

Controllers  and  pilots  should  jointly  develop  procedures  for  using 
Data  Link  ATC  services.  The  procedures  should  then  be  evaluated  in 
the  test  bed. 
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CONTROLLER  QUESTIONNAIRES 

The  controller  questionnaires  are  designed  to  obtain  feedback  from  each  controller 
participating  in  the  laboratory  test  sessions.  The  areas  covered  by  the  questionnaires 
include  the  Washington  Center  Airspace,  Test  bed  Software  Validation, 
Communications  Backup  Downlink,  and  the  D-Controller  Position.  The  questioimaires 
contain  a  description  of  each  of  the  areas  to  be  covered  in  the  test  sessions.  Included 
with  each  area  are  questions  and  comments  to  be  filled  out  by  each  of  the  test 
participants.  Please  take  time  to  read  each  question  and  provide  the  best  answer 
possible.  In  some  cases,  a  rating  scale  is  used.  Depending  on  the  question,  different 
rating  scales  will  be  used.  The  following  shows  the  values  for  each  of  the  choices  in  two 
of  the  rating  scales  used: 

Rating  Scale  1 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marpnally  Acceptable,;major  changes  necessary 

4.  Unacceptable 

Rating  Scale  2 

VG  =  Very  Good 
G  =  Good 
SG  =  Slightly  Good 
P  =  Fair 
SP  =  Slightly  Poor 
P  =  Poor 
VP  =  Very  Poor 

Any  other  rating  scales  that  are  used  will  be  explained  with  the  question.  If  there  are 
any  questions  oh  the  ratings,  ask  the  facilitator  at  your  sector.  If  there  are  any  further 
comments  or  issues  which  are  not  included,  please  write  them  down  in  the  comment 
area  provided.  If  there  is  insufficient  space,  use  the  back  of  the  sheet  on  which  the 
question  appears. 


Name 

Date  Sector 


WASHINGTON  CENTER  AIRSPACE  COMMENT  SHEET 

Four  sectors  from  the  Washington  ARTCC  have  been  implementeiin  the  Data  Link 
test  bed  to  add  realism  to  the  Data  Link  simulation.  During  the  first  night  of  tests  you 
will  be  expected  to  evaluate  and  comment  on  the  Washington  Center  airspace.  As  the 
tests  proceed  on  other  nights,  feel  free  to  come  back  to  the  comment  sheet  and  write 
down  anything  you  feel  will  benefit  the  airspace  implementation.  Following  the 
comment  sheet  are  8  pages  for  evaluation  of  each  of  the  four  new  scenarios.  Each 
sheet  should  be  completed  after  the  scenario  has  been  run.  The  facilitator  at  you  sector 
will  instruct  you  when  it  is  time  to  complete  each  scenario  evaluation.  .AJso,  answer 
the  question  at  the  bottom  of  this  page  after  the  last  night  of  testing. 


Does  the  overall  set  of  sceanrios  present  a  sufficient  range  of  operational  problems  to 
adequately  excercise  Data  Link  and  test  its  effectivness?  If  not,  what  else  is  needed? 


SCENARIO  #1  EVALUATION 


1.  Choose  the  number  below  which  best  describes  how  hard  you  were  working  during 
the  test  run. 

Description  of  Workload  Rating 

(Circle  One) 

1 

Very  Low  Workload  -  All  tasks  were  accomplished  easily  &  quickly  2 

3 


4 

Moderate  (Normal)  Workload  -  The  chances  for  error  or  omission  5 

were  low.  ‘  6 


7 

Higher  Than  Normal  Workload  -  The  chances  for  some  error  or  8 

omission  were  higher  than  normal.  9 


10 

Very  High  Workload  -  It  was  barely  possible  to  accomplish  all  11 

tasks  properly.  The  chances  for  error  or  omission  were  high.  12 


2.  Rate  your  performance  controlling  traffic  during  the  past  hour.  Circle  the  number 
which  best  describes  how  well  you  think  you  did. 

12  3  -  456789  10 

Poor  Ayerage  Excellent 

3.  How  busy  were  you  during  the  period  you  were  controlling  traffic? 

123456789  10 

Seldom  Had  Fully  Occupied 

Much  To  Do  At  All  Times 


A-3 


4.  Rate  the  degree  to  which  you  found  this  control  period  stressful.  Circle  the  number 
below  which  best  describes  how  you  felt. 

1  2  3  4  5  6  7  8  9  10 

I^w  High 

Stress  Stress 

5.  What  suggestions  would  you  make  to  improve  this  scenario? 


SCENARIO  #2  EVAtUATION 

1.  Choose  the  number  below  which  best  describes  how  hard  you  were  working  during 
the  test  run. 

Description  of  Workload  Rating 

(Circle  One) 

1 

Very  Low  Workload  -  All  tasks  were  accomplished  easily  &  quickly  2 

3 


4 

Moderate  (Normal)  Workload  -  The  chances  for  error  or  omission  5 

werelow.  6 


7 

Higher  Than  Normal  Workload  -  The  chances  for  some  error  or  8 

omission  were  higher  than  normal.  9 


10 

Very  High  Workload  -  It  was:barely  possible  to  accomplish  all  11 

tasks  properly.  The  chances  for  error  or  omission  were  high.  12 

2.  Rate  your  performance  controlling  traffic  during  the  past  hour.  Circle  the  number 
which  best  describes  how  well  you  think  you  did. 

123.  45678  910 

Poor  Ayerage  Excellent 

3.  How  busy  were  you  during  the  period  you  were  controlling  traffic? 

123456789  10 

Seldom  Had  Fully  Occupied 

Much  To  Do  At  All  Times 
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4.  Rate  the  degreeito  which  you  found  this  control  period  stressful.  Circle  the  number 
below  which  best  describes  how  you  felt. 

1  2  3  4  5  6  7  8  9  10 

Low  High 

Stress  Stress 


5.  What  suggestions  would  you  make  to  improve  this  scenario? 


TEST  BED  SOFTWARE  VALroATiON  QUESTIONNAIRE 

1.  Automatic  Transfer  of  Communication(TOC)  -  During  the  spring  testing,  the 
ATDLVT  suggested  that  auto  TGC  should  be  available  for  individual  aircraft  or  for  all 
aircraft  bound  fbr  specific  sectors.  The  test  bed  implementation  of  the  auto  TOC  only 
allows  all  aircraft  within  a  sector  to  be  in  auto  or  manual  mode.  This  limitation  is  a 
result  of  the  complexity  of  implementing  the  full  auto  TOC  into  the  NAS  software. 
Nevertheless,  the  auto  TOG  can  be  evaluated  for  its  display  attributes  and  general 
workings  with  other  NAS  functions.  The  input  action  to  enable  or  disable  auto  TOC  for 
all  aircraft  is  as  follows;  DL  CAT  KEY,  DL  Setting  CRD  input,  T,  AUTO  or  MAN. 

This  will  enable  automatic  or  manual  mode  TOG  for  all  aircraft  in  the  sector.  In 
addition,  when  a  sector  is  placed  in  the  automatic  TOG  mode,  an  "A"  will  be  displayed 
in  the  sector  setup  line  at  the  top  of  the  PVD  to  indicate  Auto  mode  enabled  for  the 
sector.  Ifthe  sector  is  in  manual  mode  an  "M"  is  displayed. 

Also  note:  When  Auto  TOG  is  enabled,  if  the  handoff  of  track  control  is  initiated 
manually,  the  handoff  input  action;  Sector  Number,  FLID  will  uplink  the  TOC 
message  upon  track  control  acceptance.  If  the  input  action;  Sector  Number,  I,  FLID 
(Inlubit)  is  used  when  TOC  is  in  Auto  mode,  the  TOC  message  will  be  placed  in  a  Held 
status  upon  acceptance  of  handoff. 

Questions: 

What  is  your  opinion  of  the  DL  CAT  KEY,  DL  Setting  CRD  input,  T,  AUTO  or  MAN 
input? 


1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 

Comments 


What  is  your  opinion  of  the  TOC  Inhibit  feature,  i.e..  Sector  Number,  I,  FLID 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 


Comments 
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How  woxild  you  rate  the  status  display  at  the  top  of  the  PVD? 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  msgor  changes  necessary 

4.  Unacceptable 

What  other  symbology  would  you  suggest? 

Overall  how  would  you  rate  the  automatic  TOC  mode? 

VP  P  SP  F  SG  G  VG 

Other  comments  and  suggestions  for  Autonmtic  TOC. 


2.  DL  /OK  With  the  S  Option  and  DL  /OK From  Any  Sector  -  During  the  spring 
testing,  when  a  track  was  stolen  using  the  /OK  option  with  the  S  the  status  of  the  TOC 
message  was  not  displayed  at  the  stealing  sector.  Try  stealing  an  aircraft  from  another 
sector  with  the  Data  Link  /OK  function.  This  will  involve  three  sectors.  Accept 
handoff  for  a  track  and  hand  that  track  to  the  next  sector  before  the  TOC  has  been  sent 
at  the  sector  with  Data  Link  eligibility.  Use  the  DL  CAT  KEY,  /OK,  S,  PLID  to  steal 
eligibility.  Observe  that  the  TOC  message  status  is  displayed  only  at  the  stealing 
sector. 

Questions: 

How  would  you  rate  the  status  list  and  Full  Data  Block  displays? 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 


Comments 


Should  the  /OK  function  be  available  for  all  sectors  who  have  had  track  control  for  an 
aircraft  but  have  handed  that  track  control  to  another  sector? 
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3.  He^  TOC  Messages  Not  Bright -  message  and  observe  that  during 

the  HELD  state  the  message  is  not  double  bright  in  the  status  list. 

Questions: 

How  wdtdd  you  rate  the  display  of  Held  TOC  messages? 

1.  Acceptable  as  is  ' 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 


Cominehts 


Can  you  find  the  Held  TOC  message  in  the  stotus  list  to  uplink?  Would  it  be  better  if 
the  message  were  displayed^as  double  bright? 


4.  Sending  Data  Link  Eligibility  -  Data  Link  eligibility  may  be  sent  to  another 
sector.  During  the  spring  tests  the  ATDLVT  suggested  new  inputs  for  uplinking=or  not 
uplinking  a  TOG  message  when  the  sector  eligibility  is  sent  to  another  sector.  The 
inputs  to  send  eligibility  and  uplink  a  TOC  message  with  the  specified  sector's 
frequency  in  the  uplink  message  is  as  follows;  DL  CAT  KEY,  Sector  Number,  FLID.  If 
the  controller  choosesmot  to  uplink  a  TOC  message.to  the  aircraft  the  following  input 
sequencers  used;  DL  CAT  KEY,  Sector  Number,  I,  FLID.  Try  sending  Data  Link 
eligibility  using  both  of  these  methods.  Evaluate  the  input  sequences  for  validity. 

Questions: 

The  input  sequence,  DL  CAT  KEY,  Sector  Number,  FLID  will  send  eligibility  and 
uplink  a  TOC  message,  while  DL  CAT  KEY,  Sector  Number,  I,  FLID  will  send 
eligibility  bvt  inhibit  the  uplink.  Hov/  would  your  rate  these  inputs: 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 


5.,  Altitude  Timeahare  r  Observe  the  timeshare  of  the  uplinked  altitude  data  and  the 
current  altitude  Pull  Data  Block  display.  Three  intervals  will  be  tested,  one  half,  one, 
and  two  seconds.  Decide  whichitime  interval  Xif  any)  works  best  for  timesharing  the 
data; 

QueBtaons;: 

How  wouldiypurate  thealtitudd  timeshare? 

1.  Acceptablerasis 

2;  Acceptable,  minor  changes,  desirable 

3..  Margirndly- Acceptable,,  major  changes  necessaiy 

4'.  thiacceptable 

Obmments; 


Which'timeshare-ihtetval.is  preferred?;'l/2;,  T,;,or!2;secondb?.  \Khy?; 
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6,  Full  Data  Block  Failure  Display  Options  -  In  the  May,  1990  controller 
evaluation,  the  entire  FDB  was  displayed  as  double  bright  when  a  Data  Link 
transaction  Failed  (i.e..  No  Pilot  Response,  Communication  Failure,  or  Pilot  Unable). 
The  general  concensus  was  that  this  Failure  display  method  was  unacceptable.  The 
current  test  provides  two  hew  generic  FDB  failure  indications.  1)  The  Data  Link 
eligibility  symbol  is  displayed  as  an  oversized  character  and  2)  The  whole  AID  field 
(1st  line  of  the  FDB)  is  displayed  as  oversized  characters.  Both  of  the  above  Failure 
methods  are  to  be  evaluated  during  the  testing. 

Questions: 

Which  of  the  alternatives  (if  any)  are  acceptable?  Why  or  why  not? 


How  would  you  rate  the  alternative  you  picked? 

VP  P  SP  F  SG  G  VG 


XT' 
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7.  Menif^  Text  Referent  in  the  SttUue  List -  The  menu  text  message  referent  and 
uplinked  altitude  data  are  displayed  in  the  Data  area  of  the  Data  Link  status  list. 
Evaluate  whether  or  not  this  data  is  displayed  appropriately  in  the  status  list. 

Sufistjons; 

How  would  you.rate  the  display  of  the  data  inithe  status  list? 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable  • 

3.  MarginaUy  Acceptable,  m^'or  changes  necessary 

4.  Unacceptable 


Comments 


Is-the  data  sufficient?  What  else  should  be  included?' 


8.  Free  Text  Recall  r-  The  input  to  recall  the  last  entered  free  text  message  is;  DL 
CAT  KEY,  T,  To  uplink  the  last  entered  free  text  message  the  inputs  are;  DL  GAT 
KEY,  T,  FLID  or\^L.  Additionally,  the  R  and  D  positions  each  have  their  own 
recallable  messages.  Evaluate  the  inputs  for  free  text  recall  and  use  the  capability  at 
both  the  R  and  D  controller  positions. 

Questions: 

What  is  your  opinion  of  the  input  DL  CAT  BEEY,  T  to  recall  the  message? 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 

Comments 


What  is  your  opinion  of  the  input  DL  CAT  KEY,  T,  FLID  or  ALL,  to  uplink  the  last 
entered  free  text  message? 

1.  Acceptable  as  is 

2.  Acceptable, .minor  changes  desirable 

3.  Marginally  Accepteble,  major  changes  necessary 

4.  Unacceptable 

Comments 


Are  recallable  messages  at  both  the  R  and  D  positions  appropriate? 


How  would  you  rate  the  Free  Text  Recall  Service? 

j  VP  P  SP  F  SG  G  VG 
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9.  Data  Link  Service  Display  in  the  Status  List  -  The  Functional  Specification 
provides  the  choice  to  display  or  not  display  each  Data  Link  service  in  the  status  list. 
Ktiie  service  is  suppressed  from  display,  normal  (i.e.,  Sent,  Delivered,  Wilco)  status 
wiUmot.be  displayed  in  the  status  list.  However,  if  a  Data  Link  message  Fails,  the 
display  of  the  message  will  be  forced  in  the  status  list,  even  if  the  service  is  suppressed 
from  status  list  display.  This  test  will  try  to  determine  which  Data  Link  services  must 
be  displayed  in  the  status  list  and  which  should  not.  The  proposed  setting  will  be: 

TOG -ON 

Altitude  Assignment -  OFF 

Free  Text  -  OFF 


QtteBtiflnsi 

Which  services  should  be  displayed  and  which  should  not?  Why? 


Should  messages  that  Fail  always  be  displayed  in  the  status  list? 


Should  Held  TOC  messages  always  be  included  in  the  status  list? 
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COMMUNICATIONS  BACKUP  DOWNLINK  QUESTIONNAIRE 


1.  D-CRD  Acknoivledgement  Button  and  Alarm  -  Determine  if  the  illumination  of 
the  D-position  GRD  Acknowledgement  button  and  D-position  alarm  are  the 
appropriate  mechanisms  for  alerting  the  controller  to  the  incoming  downlink  message. 

Questions: 

Do  the  D-CRD  Acknowledgement  button  and  D-position  alarm  provide  acceptable 
alerting  mechanisms  for  the  incoming  downlink  message?  How  would  you  rate  the 
alerts? 


1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 


Comments 


2.  Downlink  Message  Display  -  Evaluate  the  D-CRD  acknowledgement  button  for 
displaying  the  communications  backup  downlink  message.  Determine  if  the  message 
referent,  time  of  receipt  of  the  message,  AID,  and  the  downlink  text  are  displayed 
properly  in  the  D-position  CRD. 

Questions: 

How  would  you  rate  the  display  of  the  downlink  information? 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 


Comments 
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Is  the  use  of  the  D-CRD  Acknowledgement  key  to  display  downlink  messages 
acceptable?  What  if  the  communications  backup  downlink  messageCs)  are  mixed  with 
other  messages  sent  to  the  D-position?  Will  this  pose  any  potential  problems? 


Is  all  the  information  that  is  currently  displayed  with  the  downlink  message 
appropriate? 


Is  there  any  additional  information  that  needs  to  be  included? 


3.  Flight  Strip  Printer  (FSP)  Data  Display  -  Examine  the  display  of  the  data  on 
the  flight  strip  printer.  Comment  on  the  PSP  fields  used  for  display  of  the  downlink 
message  and  associated  data. 

Questions: 

How  would  you  rate  the  FSP  output? 

1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

3.  Marginally  Acceptable,  major  changes  necessary 

4.  Unacceptable 

Comments 
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Is  the  data  displayed  in  the  proper  fields  of  the  FSP?  If  not,  which  data  should  be 
displayed  in  which  fields  of  the  PSP  output? 


Should  color  be  used  to  distinguish  certain  fields  (i.e.,  Red  or  Black)? 


Will  the  flight  strip  print-out  be  required  as  soon  as  the  downlink  message  is  received? 


Do  all  downlink  messages  need  to  be  printed  out  on  the  FSP? 


4.  Acknowledgement  of  the  Downlink  Message-  Detejmine  if  the  keyboard  inputs 
required  for  response  to  the  downlink  message  are  appropriate.  The  input  sequence  to 
acknowledge  the  downlink  message  is;  ACK  QAK  (new  QAK  at  D-positiori),  referent 
number,  and  optionally  a  response.  If  no  response  is  included  in  the  message,  a 
default  response  (i.e.,  Standby)  will  be  generated  and  sent  to  the  pilot.  Allowable 
values  for  the  response  are  S  for  Standby,  R  for  Roger,  A  for  Approved,  and  IT  for 
Unable. 

Questions: 
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1.  Acceptable  as  is 

2.  Acceptable,  minor  changes  desirable 

'3.  Maipnally  Acceptable,  major  changes  necessary 
4.  Unacceptable 

Consents 


Does  t^e  controller  have  to  respond  to  a  Communications  Backup  Downlink  message? 


What  should.the  defatdt  response  to  the  downlink  message  be?  Should  there  be 
additional  allowable  values  for  the  response? 


5.  Overall  Assessment 

How  would  you  rate  the  Communications  Backup  Downlink  service  overMl? 

VP  P  SP  F  SG  G  VG 
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D-POSITION  QUESTIONNAIRE 


The  D-Contrbller  position  has  been  cited  as  a  potential  candidate  for  performing 
certain  Data  Link  functions  by  the  ATOLVT  in  the  past.  In  previous  Data  Link  tests 
the  D-position  has  hot  been  utilized.  Now  with  the  current  downlink  design  and  the 
potential  benefits  of  the  D-position  used  in  conjunction  with  Data  Link,  the  necessity 
for  including  the  D-position  has  become  apparent.  The  current  exercise  is  intended  to 
solicit  ideas  about  the  use  of  the  D-position.  Functions  and  responsibilities  of  the  D- 
position  and  the  potential  workload  reduction  on  the  R-positionare  the  focus  of  this 
effort.  Also  the  questionof,  Can  the  inclusion  of  the  D-position  increase  an  entire 
sector's  capacity?  should  be  asked. 

During  the  1  hour  test,  two  controllers  will  be  present  at  , each  sector  position.  They 
will  take  on  the  roles  of  the  R  and  D-controllers.  Half  way  through  the  test  run  the 
controllers  should  switch  roles  so  each  controller  can  give  a  proper  evaluation  of  the  ,D- 
position  issues. 

A  starting  point  for  the  test  should  be  to  define  which  Data  Link  functions  the  D- 
position  can  perform  (e.g..  Downlinks,  Hand^offs).  Also,  thought  should  be  given  as  to 
how  future  evaluations  should  be  conductedi  Future  tests  will  be  conducted  to  answer 
the  questions  and  issues  raised  above. 

1.  D-Position  Fuiictiom  -  Comment  on  the  Data  Link  functions  that.can  be 
performed  at  the  D-position. 


2:.  Fiuftire  JSibaZtta/ibiM >  Cbimnent  on  how  future  Data  Eink  testing 

conducted'  to  helpianswer  theiquestions  of  increasing  ai  sector's  ejBRciency  and  reducing. 

workload  ontheR'positibm. 


APPENDIX  B 

CONTROLLER  DISCUSSION  ISSUES 


CDI  #:  El-091390  PRIORITY:  HIGH 

CTR  REFERENCE  #: 

TITLE:  DOWNLINK  NONRESPONSE  TIMEOUT 
SYSTEM:  En  Route 

DESCRIPTIpN:  If  controller  does  not  respond  to  a  downlink 

should  there  be  a  tiineout  alert.  The  following  are  possible 
scenarios:. 

1.  Pilot  side  times  out  giving  some  kind  of  alert.  The  pilot 
will  resend  or  delete  and  call. 

2.  No  pilot  side  timeout.  It  will  remain  steady,  no  alert. 

,  I 

3.  Controller  side  will: 

a.  Remain  stable  with  no  alert  and  no  block  of  response. 

b.  Show  alert  but  with  no  block  of  uplinked  response. 

c.  Show  alert  and  block  uplinked  response  (since  pilot  side 
has  timed  out) . 


SUGGESTED  SOLUTION: 


RESOLUTION:  The  ATDLVT  recommended  at  the  the  Nov  5-9  Technical 
Center  Meeting  that  this  issue  be  re-examined  and  this  CDI 
discussed  at  a  future  design  discussion  meeting  on  downlinks. 
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BN  ROUTE  CDlm 


CDZ  «t  E2-091390  PRIORITY:  HIGH 

CTR  RBrBRBNCB  «: 

TITLB:  NAX«d  RESPONSES  TO  DOWNLINKS 
SYSTEM:  En  Route 

DESCRIPTION:  All  downlinks  need  to  be  resp>mded  to  by  approve, 

disapprove,  (whatever).  This  constitutes  an  uplink  which 
unfortunately  can  run  afoul  and  get  a  negative  acknowledgement 
(NAK)  on  the  uplink.  How  will  this  be  shown? 


SDOGESTEb  SOLUTION:  In  the  status  list  where  it  can  be  slewed  for 
rdsendihg. 


RESOLUTION:  The  ATDLVT  concurred  with  the  suggested  solution  above 
at  the  Nov  5-9  1990  Technical  Center  Meeting.  The  ATDLVT  also 
stated  that  this  issue  should  be  re-examined  at  a  future  design 
discussion  meeting  on  downlinks. 
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EN  ROUTE  GDIS 


GDI  #:  E4-091390  PRIORITY;  HIGH 

CTR  REFERENCE  #: 

TITLE:  STEALING  DL  DELETES  MESSAGES. 

SYSTEM:  En  Route 

DESCRIPTION:  Sometimes  a  controller  need  steal  DL  eligibility. 

Should  this  be  allowed  if  a  message  is  held,  pending,  failed/ 
unabled,  out?  or  a  downlink  is  pending  or  with  failed  out?  uplink 
response. 


SUGGESTED  SOLUTION: 


RESOLUTION:.  The  ATDLVT  stated  the  following  concerning,  this  issue 

at  the  Nov  5-9  1990  Technical  Center  meeting: 

1.  A  controller  cannot  steal  data  link  eligibility  without  track 
control . 

2 .  A  controller  cannot  steal  track  control  with  data  link 
messages  pending. 

3.  A  controller  shall  not  hand  off  while  a  data  link  message  is 
pending. 
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Bir  RggTB  CPIg 

CDl  #t  E9-091390  PRIORITY:  HIGH 

CTR  REFERENCE  #: 

TITLE:  DOfmLINK  R  AND  D  SIDE 
SYSTSN:  En  Route 

DESCRIPTION:  On  the  bulletin  board,  Charles  Scanlon  Indicates 

what  pilots  would  like  in  terms  of  downlink.  A  copy  is  attached. 

REROUTE  downlink  was  especially  liked.  This  is  a  host  function  for 
most  facilities  but  DL  can  do  it  for  ARTS  also  since  it  interfaces 
with  host.  AAS  for  sure.  They  will  be  looking  at  4-D  flight  paths 
in  future. 

PREDEPARTURE  CLEARANCE  downlink  was  unanimously  accepted. 

AIRSPEED,  HEADING,  ALTITUDE  and  FREE  TEXT  requests  were  all 
unanimously  wanted  but  were  sometimes  voiced  instead  by  the  pilots 
in  their  tests. 


^SUGGESTED  SOLUTION:  Pilot  ideas  suggest  downlink  is  a  general 
function  not  an  emergency  function  and  that  downl’inks  should  be 
treated  just  as  importantly  as  pilot  call  by  the  R  side  as  well  as 
D  side. 


RESOLUTION:  The  ATDLVT  recommended  at  the  Nov  5-9  1990  Technical 
Center  meeting  that  this  issue  be  re-examined  and  this  CDI 
discussed  at  a  future  design  discussion  meeting  on  downlinks. 
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EN  ROUTE  CDI3 

GDI  #:  ElO-091390  PRIORITY:  HIGH 

CTR  REFERENCE  #: 

TITLE:  SPEEDS  AND  HEADINGS  IN  MENU 
SYSTEM:  En  Route 

DESCRIPTION:  Suggest  that  en  route  have  adaptable  heading  and 

speed  menu  messages  like  altitude.  When  sent,  status  indications 
would  be  like  free  text. 


Heading  and  speed  MT  entries 

To  send  MT  message  DL,  MT  referent,  FLID 

To  Send  MT  &  change  three  digits  DL,  MT  referent,  nnn,  FLID 
To  change  &  retain  MT  three  digits  DL,  MT  enter 


SUGGESTED  SOLUTION: 


RESOLUTION:  The  ATDLVT  recommended  at  the  Nov  5-9  1990  Technical 
Center  meeting  that  this  isSue  be  re-examined  and  this  CDI 
discussed  a  future  design  discussion  meeting. 
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EN  ROOTB  CDI» 

CDZ  It  E2-lbl890  PRIORITY!  HIGH 

CTR  RErEREMCE  It 

TITLE t  MULTIPLE  MESSAGES  FROM  MENU  TEXT 
8UPPLEKBMTAL  DATA!  ORIGINATOR  -  EVAN  DARBY 
SYSTEM!  HOST 

DESCRIPTION!  The  controller  should  have  the  ability  to  send  more 
than  one  menu  text  message  to  an  aircraft.  By  combining  messages 
the  controller  could  be  more  efficient  and  Data  Link  will  become 
even  more  powerful. 


SUGGESTED  SOLUTION: 

Allow  multiple  Data  Link  menu  text  selections .  These  selections 
should  be  tied  together  to  form  one  clearance  and  then  sent  to  the 
aircraft.  The  pilot  must  either  accept  the  entire  Qlearance  or  the 
entire  clearance  is  v6id.  This  eliminates  the  problem  of  partiai 
clearances  being  used. 

EX.  "DL”  A  C  F  (CID); 

.A  +  Climb  and  Maintain  FL  230 
.C  Maintain  250  Kts 

.F  Fly  Heading  060  Vectors  for  Spacing 


RESOLUTION:  The  ATDLVT  concurred  with  the  above  solution  at 
the  Nov  5-9  1990  Technical  Center  meeting.  The  ATDLVT  stated 
emphatically  that  when  more  than  one  menu  text  message  is  sent  to 
an  aircraft,  multiple  messages  of  the  same  type  may  not  be 
uplinked/  i.e.,  multiple  speeds,  altitudes,  etc. 
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BN  RODTB  GDIS 


CPI  *t  EiO-030990  PRIORITY;  High 

GTR  RBFBRENCB  *t  90030602 

TITLE;  INTERFACILITY  DL  PROCESSING 

stjppLEMENTAL  DATA;  Problem  Area:  Design 

SYSTEM;  En  Route 

DESCRIPTION;  The  purpose  of  this  CTR  is  to  develop  the  functional 
processing  requirements  for  Data  Link  interfacility  processing,  and 
to  suggest  that  the  approach  in  the  Data  Link  functional 
specification  be  tested.  That  approach  incorporates  a  new 
interfacility  message>  which  will  facilitate  Data  Link  Transfer  of 
Communications  (TOC)  for  handoffs  ARTCC/ARTCC  and  ARTCC/TRACpN . 

In  that  approach,  presented  herein,  an  interfacility  Status  Update 
(SU)  message  contains  AID,  a  Reference  Number,  Transaction  Status 
and  operation  data  such  as  radio  frequency.  This  message  will  be 
generated  by  the  sending  computer  and  will  be  used  to  update 
transaction  status  in  the  receiving  computer  when  a  TOC  involves 
more  than  one  facility.  Below,  SU  message  applications  to  normal 
interfacility  TOC,  and  to  forcing  ahd  stealing  Data  Link 
eligibility  are  discussed. 

I.O  Normal  Handoff  and  Transfer  of  Communication 

Figure  1  contains  a  diagram,  which  is  referenced  by  the  description 
of  interfacility  Data  Link-  activity  presented  below.  For  an 
aircraft  having  Data  Link  session  connectivity  to  the  computers  in 
both  facilities,  interfacility  transfers  of  track  control,  radio, 
frequency  assignment  and  Data  Link  eligibility  can  be  accomplished 
as  follows: 

.  To  initiate  a  transfer.  Position  A  in  facility  A  enters 
track  handoff  to  position  B  in  facility  B.  "H-xx”  blinks  in  both 
data  blocks.  The  full  data  block  at  A  indicates  Data  Link 
eligibility.  The  full  data  block  at  B  indicates  Data  Link- 
capability. 

.  When  the  Controller  in  B  accepts  handoff,  and  "0-xx"  is 
displayed  in  both  data  blocks,  a  HELD  Data  Link  message  having  B's 
radio  frequency  is  generated  and  displayed  in  A's  status  list. 
Generation  of  this  message  initiates  a  TOC  transaction.  Full  Data 
Block  capability/eligibility  symbols  operate  the  same  as  with 
ihtrafacility  TOC. 

.  An  SU  message  is  built  and  transmitted  to  B.  The  SU 
message  indicates  HELD,  the  radio  frequency  and  the  unique 
transaction  identifier  (reference  number) i  In  B,  this  information 
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is  displayed  the  same  as  transaction  information  for  intrafacility 
handoffs. 


.  The  controller  in  A  uplinks  the  message  to  the  aircraft. 
As  Status  changes  to  SENT,  DELIVERED  and  WILCO,  or  FAIL,  each 
status  change  is  sent  to  B  via  an  SU  message. 

.  VWien  the  status  changes  to  WILCO,  the  B  computer  assigns 
Data  Link  eligibility  to  position  B,  in  accordance  with  the 
requirements  for  granting  Data  Link  eligibility.  The  Full  Data 
Block  symbol  changes  to  indicate  eligibility.  At  A,  the  A  computer 
changes  the  Full  Data  Block  symbol  to  indicate  Data  Link 
capability,  not  eligibility,,  in  the  same  way  as  for  intrafacility 
TOC. 


.  The  pilot  changes  frequency  and  calls  B.  First  call  and 
initial  contact  may  be  executed. . 

It  should  be  noted  that  computer  tables  of  radio  frequencies  must 
include  all  of  those  used  for  interfacility  transfers. 

2.  Forcing  Data  Link  Eligibility 

When  a  track  enters  a  facility  and  Data.  Link  eligibility  has  not 
been  established  for  a  position  within  that  facility,  a  process 
similar  to  track  initiation  should  be  used  for  forcing  Data  Link 
eligibility.  In  today's  AT.C  system,  ah  en  route-  sector  can  force 
TRACK  control  by  entering  "/pK"  and  the  .1:rack  identification.  For 
Data  Link  eligibility,  the  following  procedure  is  suggested. 

.  The  sector  desiring  Data  Link  eligibility  for  the  aircraft 
must  first  acquire  track  control.  This  control  is  acquired  by 
automatic  track  initiation,  manual  input  action  to  initiate  a 
track,  or  by  using  "/OK"  to  force  a  handoff  to  the  entering  sector. 

.  After  acquiring  track  control,  the  sector  PVD  will  display 
the  full  data  block  with  the  Data  Link-capability  symbol  indicating 
that  a  Data  Link  session  is  established  for  the  aircraft.  To 
acquire  Data  Link  eligibility,  the  sector  with  track  control  should 
enter  the  Data  Link  Categbry/Function  key  and  "/OK"  for  the 
aircraft  ID.  The  computer  would  assign  Data  Link  eligibility  to 
the  entering  sector.  If  the  operational  "S"  were  entered,  an 
uplink  message  would  be  built  with  that  sector's  radio  frequency, 
and  would  be  uplinked  to  the  aircraft.  The  transaction  status 
would  be  set  to  "SENT",  and:  further  processed  according  to  Data 
Link  requirements. 

In  the  above  example,  no  SU  message  is  generated.  The  computer 
does  not  know  which  external  facility,  if  any,  previously  had  Data 
Link  eligibility.  It  is  expected  that  operational  coordination 
among  facilities  will  ensure  that  only  one  controller  issues 
operational  directives  to  the  pilot,  as  is  the  case  in  today's  ATC 
facilities. 
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In  the  above  approach,  the  SU  message  only  updates  transactions 
between  facilities,  and  no  messages  are  required  to  deal  directly 
with  eligibility  assignments  between  facilities. 

3.  Stealing  Data  Link  Eliaibilitv 


To  eliminate  the  possibility  of  a  controller  in  one  facility  having 
DL  eligibility  with  an  aircraft  at  the  same  time  as  a  controller 
in  another  facility,  interfacility  messages  might  be  generated  to 
be  specifically  used  for  eligibility.  But,  multiple  eligibility 
is  rtpt  clearly  a  problem-.  On  the  contrary,  some  advantage  might 
accrue  from  providing  an  interface  between  a  pilot  and  ATG  in 
parallel  with  the  control  interface,  e.g.,  for  nonoperational 
information  transfer. 

A  problem  occurs  if  more  than  one  controller  issues  an  operational 
command, to  an  aircraft. 

If  a  controller  uplinked  an  invalid  command,  any  ability  to  steal 
DL  eligibility  from,  another  controller  enables  this  problem, 
regardless  of  interfacility  computer  messages  that  might  be 
associated  directly  with  eligibility.  For  a  computer-based 
interfacility  eligibility  control  mechanism  to  be  effective,  a 
"negotiation'?  process  would  be  necessary,  where  a  controller 
"requests"  eligibility  from  some  other  facility. 

However,  a  negotiation  process  would  be  neither  practical  nor 
necessary.  To  execute  a  hegptiation  process,  the  stealing 
controller,  or  Host  computer,  must  send  a  request. 

A  sector  with. DL  eligibility  could  ignore  or  refuse  the  request. 
On  what  basis  is  that  decision  made?  Would  not  there  be  a  need  to 
determine  what  that  facility  ih  requesting,  DL  eligibility,,  and  what 
they  inters  ta  do  with  it? 

Why  would  interfacility  messages  be  needed  to  request  Data  Link 
eligibility  if  subsequent  coordination  results  anyway? 

To  summarize,  using  interfacility  messages  to  ensure  that  only  one 
controller  maintains  eligibility  throughout  all  of  the  ATC 
facilities,  who  currently  are  capable  of  DL  communications  with  an 
aircraft,  would  require  a  negotiation  process.  At  this  time,  the 
need  for  such  a  process  is  not  apparent. 

It  is  therefore  suggested  that  the  test  bed  provide  Host/ARTSIII 
interfacility  testing  as  soon  as  possible,  execute  SU  message  to 
keep  both  systems  updated  for  interfacility  TOCs,  and  that  Data 
Link  eligibility  be  assigned  within;  a  facility. 

Both  Host  and  ARTSIII  software  should  therefore  be  modified  to 
execute  SU  message  generation  and  reception. 

RESOLUTION:  The  ATDLVT  recommended  at  the  Nov  5-9  1990  Technical 
Center  meeting  that  this  issue  be  re-examined  and  this  GDI 
discussed  at  a  future  design  discussion  meeting. 
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EN  RODTE  GDIs 


GDI  #:  £5^091390  PRIORITY:  MEDIUM 

CTR  REFERENCE  «: 

TITLE;  SECTOR  FREQUENCY  CH^GE 
SYSTEM:  En  Route 

pESCRTPTION:  If  a  frequency  goes  bad,  the  controller  may  need 

to  switch  to  another  one.  At  the  same  time  the  controller  needs 
to  change  the  frequency  associated  to  his  sector  in  the  computer 

table.  I  suggest  menu  item  F  "change  to  my  freq— , - When 

sent  to  ALL,  it  changes  the  computer  table.  If  sent  to  one  flid, 
it  does  not  change  the  table. 

The  initial  sewices  spec  says  that  frequency  changes  for  the  TOC 
table  can  only  be  done  by  the  supervisor. 


SUGGESTED  SOLUTION: 


RESOLUTION:  The  ATDLVT  stated  at  the  Nov  5-9  1990  Technical  Center 
meeting  that  frequency  changes  should  only  be  done  by  the 
supervisor. 
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PRIORITY:  LOW 


EW  ROUTB  CDI8 


CDI  ft  E8 -09 13 90 

CTR  REFERENCE  #: 

TITLE:  QQ  S  FLIP  TO  UPLINK  REQUESTED 

SYSTEM:  En  Route 

DESCRIPTION:  The  entry  QQ  FLID  overwrites  the  interim  altitude 

in  the  FDB  with  the  requested.  The  entry  QQ  S  FLID  seems  like  the 
logical  entry  to  uplink  it  also.  This  is  because  QQ  ddd  FLID 
becomes  uplinked  by  adding  an  S,  eg.  QQ  ddd  S  FLID.  However,  the 
designed;  entry  is  DL  R  FLID.  I  suggest  it  be  changed  to  QQ  s  FLID 
because 

1.  It  frees  up  R  to  be  used  for  "Roger”  response  to  downlinks. 

2.  It  shortens  the  menu  text  list. 

3.  It  is  consistent  with  "S"  design. 


SUGGESTED  SOLUTION:  Use  QQ  S  FLID  to  put  requested  in  FDb  and 
uplink  it. 


RESOLUTION:  The  ATDLVT  did  not  concur  with  this  CDI  at  the  Nov  5- 
9  1990  Technical  Center  meeting.  The  ATDLVT  stated  that  "S"  means 
send  and  the  controllers  want  this  to  remain  a  clear  fact. 
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EN  ROUTE  CPIs 

GDI  #:_  El-101890  PRIORITY:  LOW 

CTR  MFERENCE  #: 

TITLE;  PRINT  MENU  TEXT  MENU 
SYSTEM:  En  Route 

SUPPLEMENTAL  DATA:  ORIGINATOR  -  EV;^  DARBY 
DESCRIPTION: 

For  the  most  part  controllers  do  not  lil^®  to  have  listed  displayed 
on  their  PVD's.  Cpntrollers  must  already  watch  their  Metering 
list.  Conflict  alert  list,  MCI  list  and  up  to  three  optional  lists. 

There  must  be  some  other  optional  method  for  viewing  or  referring 
to  data  in  the  menu  text  list. 


SUGGESTED  SOLUTION: 

Allow  the  controller  to  print  the  Data  Link  menu  text  list  oh  the 
FSP. 

Possible  entry  could  be: 

”DL»  (FSP  #)  (MT)  (Tlnter) 


RESOLUTION:  The  ATDLVT  approved  this  CDI  for  test  bed 

implementation  at  the  Nov  5-9  1990  Technical  Center  meeting. 
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BN  ROPTE  CPIS 

CDI  #,:  E3-I01890  PRIORITY:  LOW 

CTR  RBrEREMCE  «: 

TITLE:  ADDITIONAL  DATA  B^OCK  INFORMATION 

SUPPLEMENTAL  DATA:  ORIGINATOR  -  EVAN  DARBY 

systom:  host 

DESCRIPTION:  During;  an  altitude  uplink  there  exists  the  possibility 
for  information  to  reach  the  pilot  and  then  either  time  out  or  be 
pilot  unabled.  In  either  case  the  controller  needs  to  know  that 
the  pilot  has  the  information  available  to  him.  The  controller 
philosophy  in  the  past  has  been  all  we  need  to  know  is  did  the 
message  faH  or  not.  This  concept  has  some  merit  but  is  hot 
entirely  true.  If  the  downlink  of  the  WiLCO  message  should  fail 
for  some  reason  the  pilot  may  be  complying  with  the  clearance  and 
the  data  block  still  reflects  a  FAIL  status. 


SUGGESTED  SOLUTION: 

Change  the  data  block  symbology  to  include  the  ’^D”  for  delivered. 
This  would  be  displayed  in  the  data  block  after  the  technical 
acknowledgement  was  received  from  the  aircraft  between  the  "S”  for 
sent  and  the  "W"  for  wt'lco.  Now  the  controller  would  have 
information  available  on  the  status  of  the  message  not  just  the  and 
result  and  could  take  appropriate  actions. 


EM  ROUTE  CDIa 

CDI  #:  E7-091390  PRIORITY:  LOW 

CTR  REFERENCE  #: 

TITLE:  STAITJS  LIST  SUPPRESSION  OVERRIDE 


SYSTEM:  En  Route 

DESCRI^IOM:  Even  though  the  status  list  may  be  suppressed, 

display  NAKs,  fails,  unables,  and  held  messages,  since  they  need 
attention,  and  can  be  slew  entered  from  the  list. 

The  initial  eh  route  spec  has  this  feature  but  does  not  include 
held  TOCs. 


SUGGESTED  SOLUTION: 


RESOLUTION: 

The  ATDLVT  stated  at  the  Nov  5-9  1990  Technical  Center  meeting  that 
NAKs,  FAILS,  UNABLEs,  and  HELD  message  displays  should  appear  on 
the  PVp  even  though  the  status  list  may  be  suppressed. 
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APPENDIX  C 
SECTOR  DESCRIPTIONS 


Leesburg  En-Route/Sim-Pilot  Lab  Pairings 


Controller  sector 

Pilot  Lab  Console 

Frea. 

Pilot  1 

30 

34,35,36 

125.750 

Pilot 2 

32 

17 , 18 , 19 

133.720 

Pilots 

60 

22, 23;,  24 

135.400 

Pilot4 

31 

37,38,39 

124.250 

Departure  Ghost 

69 

20,33 

Intercom  only 

Arrival  Ghost 

57 

21,40 

111.100 
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ZOC  -  WASHWGTON  CENTE^ 

HKSH  ALflTUDB  FREQUENCIES  i  DIAL  C( 


RCAC  SITES 

A  -  ELKINS 
3  -  GKANTSVitLE 
C  -  LINDEN 
;D  -  BUC^  ELBOV 
E  -  HAGEKSTOWN 
P  -  BALTIMORE 
C  -  KENTON 
H  •  PATUXENT 
I  -  GREEN  BAY 


BUENA  VISTA 
NOT  USED 
SOUTH  BOSTON 
SEA  ISLE 
CAPE  CHARLES 
WKAUYVILLE 
JOHNSONVILLE 
ROCKY  MOUNT 
NEW  BERK 
SAMPSON 


AAL  AMERICAM 
ACA  AIR  CANADA 
AHI  AIR  WISCONSIN 
CDL  CAROLINA 
CRQ  CHAUTAUQUA 
COA  CONTINENTAL 
COM  COMAIR 
OJ^  DELTA 
EAL  EASTERN 
HNA  HENSON 
JIA  BLUE  STREAK 
MXA  MEXICMIA 
MAE  EAGLE  FLIGHT 
QXC  QUAKER  CITY 
R  ARMY 
S  SAM 
TWA  TWA 
UAL  UNITED 
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LOCATION  IDENTIFIERS 


AON 

ANDREWS  AFB 

BAL 

BALTIMORE,  MD 

BCB 

BLACXSBURG,  VA 

BKN 

BECXLEY,  WV 

BLF 

BLUEFIELD,WV 

BRV 

BROOKE,  VA 

BUY 

BURLINGTON,  NC 

BWI 

BALTIMORE  WASHINGTON 

INTL  AIRPORT 

CAE 

COLUMBIA,  SC 

CHO 

CHARLOTTESVILLE,  VA 

CHS 

CHARLESTON,  SC 

CKB 

CLARKSBURG,  WV 

CLT 

CHARIOTTE,  NC 

CRW 

CHARLESTON,  WV 

CSN 

CASANOVA,  VA 

CTF 

CHESTERFIELD,  SC 

DAA 

DAVISON  AAF 

DAN 

DANVILLE,  VA 

DCA 

WASHINGTON  NATIONAL 

EKN 

ELKINS,  WV 

EMI 

WESTMINISTER,  MD 

ESL 

KESSEL,  WV 

ENR 

NEWARK,  NJ 

FAX 

FLAT  ROCK,  VA 

FAY 

FAYETTEVILLE^  NC 

FBG 

FORT  BMGG,  NC 

FDK 

FREDERICK,  VA 

FLM 

FAIMOUTH,  VA 

FLO 

FLORENCE,  SC 

FVX 

FARMVILLE,  VA 

6SB 

SEYMOtm  JOHNSON  AFB, 

NC 

GSd 

GREENSBORO,  NC 

GVE 

GORDONSVILLE,  VA 

HXY 

HICKORY,  NC 

HPW 

HOPEWELL,  VA 

HSP 

HOT  SPRINGS,  VA 

HTS 

HUNTINGTON,  WV 

HVQ 

CHARLESTON,  WV 

HYX 

LEXINGTON,  KY 

lAO 

WASHINGTON  DULLES  INTL  AIRPORT 

IXB 

WXLKESBORO,  NC 

INT 

WINSTON  SALEM,  NC 

ISO 

KINSTON,  NC 

JYO 

LEESBURG,  VA 

LBT 

LUMBERTON,NC 

LFI 

LANGLEY  AFB,  VA 

LIB 

LIBERTY, NC 

LHB 

LEWISBURG,  VA 
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LYH  LYNCHBURG^  VA 

MGN  MORGANTOWN,  WV 

MOL  MONTEBELLO,  VA 

MRB  MARTXNSBURG,  WV 

MTV  MARTINSVILLE,  VA 

ORF  NORFOLK,  VA 

OTT  NOTTINGHAM,  MD 

FOB  FOFE  AFB,  NC 

PSX  DUBLIN,  VA 

PXT  PATUXENT  RIVER  NAS  ,  MD 

KX  RALEIGH/DURHAM,  NC 

RIC  RICHMOND,  VA 

RNL  RAINELLE,  WV 

ROA  ROANOKE,  VA 

SBV  SOUTH:  BOSTON,  VA 

SBY  SALISBURY,  MO 

SDZ  SANDHILLS,  NC 

SHD  SHENANDOAH  VALLEY  ARPT,  VA 

SIF  REIOSVILLE,  NC 

SOP  SOUTHERN  PINES  NC 

SPA  SPARTANBURG,  SC 

M40  ABERDEEN/MORY,  MD 

WIO  MANASSAS,  VA 

W13  WAYNESBORO,  VA 

W16  WINCHESTER,  VA 

W52  CHAPEL  HILL,  NC 

W54  -WESTMINSKR,  MD 

W78  SOUTH  BOSTON,  VA 

W93  ORANGE  CO. ,  VA 
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sector  30 

HOT  SPRINGS  msP^  29 /VALLEY  SECTOR  30 

1.  General  Description;  The  Valley  Sector  (R30)  serves  as  a 
cieparture  sector  for  two  main  airports  in  the  middle  western 
Virginia  (Roanoke  and  Lynchburg) .  This  sector  will  be  combined 
with  Hot  Springs  for  the  purposes  of  our  testing  and  serves  as 
approach  control  for  the  Lewisburg/Hot  Springs  and  Lynchburg, 
Airports.  The  basic  altitudes  are  FL230  and  below,  with  Roanoke 
approach  owning  10,000  and  below.  The  two  primary  very  high 
frequency  omnidirectional  ranges  (VOR's)  are  Roanoke  (ROA)  and 
Lynchburg  (LYH)  There  are  instrument  approaches  for  all  major 
airports  in  the  sector.  There  are  VFR  towers  at  Lynchburg  and 
Lewisburg,  Virginia.  Due  to  mountainous  terrain,  the  minimum 
vectoring  altitude  is  6000  feet. 

2.  Radio  Frequencies;  For  the  purpose  of  this  test,  the 
frequencies  for  sector  29/30  will  be  123.000. 

3 .  Procedures ; 


A.  Roanoke  Approach 
1.  Arrivals: 


a.  Shall  cross  25  miles  from  the  Roanoke  VOR 
level  at  110  and  250  Kts.  Hand-Offs  shall 
be  accomplished  prior  to  the  Aircraft 
crossing  the  approach  boundary. 

b.  Roanoke  arrivals  operating  at  or  below  10,000  feet 
shall  be  verbally  coordinated  with  Roanoke  approach 
prior  to  hand-off.  All  coordination  involving 
facilities  other  than  sectors  29/30,  31,  32  and  60 
will  be  accomplished  with  sector  (69  Ghost) . 

2.  Departures ; 

a.  All  Roanoke  departures  will  be  climbing  to  10,000 
feet  or  their  assigned  altitude  if  less  than  10,000 
feet. 

b.  All  roahoke  departures  will  be  established  on  their 
correct  route  of  flight  before  being  handed-off  to 
center. 
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B.  VFR /-Towers ; 

1 .  Center  Procedures : 

a.  All  flight  plans  shall  be  issued  to  the  tower 
at  least  10  minutes  prior  to  their  departure  times : 

1.  Aircraft  Id. 

2.  TypB  A/C-Beacon  Code 

3 .  Route/Destlnatipn 

4i  Altitude  to  expect  10  inln.  after  Dept. 

b.  All  inbound  flight  plans  shall  be  given  to  the 
tower  15  minutes  prior  to  Destination  time: 

1.  Aircraft  -Id. 

2.  Type  A/C. 

3.  Type  of  Approach 

4.  Arrival  Time 

c.  When  towers  call  for  RLS  of  aircraft  the  center 
shall  issue: 

1.  Initial  HDG. 

2.  Initial  ALT. 

2 .  Tower  Procedures : 

a.  When  towers  call  for  RLS  they  shall  provide  the 
active  RWYi 

b.  Tower  is  resnonslble  for  the  visual  separation 
between  arrivals  and  departures. 

c.  Tower  shall  call  and  advise  the  center  when  an  A/C 
in.  insight  landing  assured. 

C.  Over  Flight  Procedures: 

1.  Raleigh'Durham  arrival  traffic  shall  enter  South  Boston 
Sector  (69)  Ghost  at  or  below  FL210. 

2.  Non- Jet  arrival  traffic  to  Baltimore,  Washington, 
Richmond  and  satellites  operating  at  or  above  17,000 
feet  shall  be  handed-off  to  AZALEA  (31)  at  or  below 
15,000  feet. 

3.  Arrivals  to  Raleigh  Co.  (BKW)  shall  be  handedroff 
directly  to  Charleston  approach  (69  Ghost)  at  or  below 
10,000  as  coordinated. 

4.  Arrivals  to  Charleston,  WV  operating  above  16,000  feet 
shall  cross  the  common  boundary  at  or  below  FL230 
descending  to  16,000. 
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Roanoke  Arrivals  X  25  miles  from  ROA  §  lio  and  250  Kts 

Roanoke  Departures  Climbing  to  10,000  on  corse 

Raleigh-Durham  Arr  South  Boston  8  or  Below  FL2iO 

Non-Jet  Traff is  to  8  or  below  15,000  (31  AZALEA) 

Baltimore  (BWI) 

Washington  (DCA)/(IAO) 

Richmond  (Ricj 
Satellites 

Raleigh  Co.  (BKW)  Arr  8  or  below  10,000  (69  Ghost) 

Charleston  Arr  Decending  to  16,000  (69  Ghost) 


Valley 

sector 

30 

125.750 

Azalea 

sector 

31 

124.250 

Gordonsviile 

sector 

32 

133.720 

Montebello 

sector 

60 

135.400 

Ghost  Departures 

sector 

57 

Arrival  Ghost 

69 

lll.lOO 

Roanoke  Apprpach 

69 

ill i 100 

Lynchburg  Tower 

lll.lOO 

All  Towers 

111.100 

Lynchburg  Airport  Elev  -  938  feet  MVA  -  6000  RWY  36/18 
All  departures  are  using  RWY  36. 


Ingalls  Field  (HSE)  Elev  -  3792  feet  MVA  -  6000  RWY  9/24 

NDB  RWY  24  245  deg  lA  5400 

ILS  RWY  24  245  deg  lA  5400 


SECTOR  30  -  VALLEY 
.‘•51?  A‘-T'tude  sector 


MBINE 


!  125.756 
124.250 
133.720 
135.400 
111.100 


CHOSf SECTOR 
(69) 


AZA(31 

8FC-1$( 


08T 

BTOR 

S9) 


GH08T  SECTOR  (69) 
240  AND  ABOVE 


m(30) 

8FC*230 


y  240-270 


MOL(00) 

170-270 

B 


VAL(30) 

010-230 


ROANOKE 
AFP  (69) 
SFC-010 


GHOST  SECTOn(69) 
240  AND  ABOVE 


VAL(30r 

^»PC.230 

LYH 


/SVB(32} 

4240^ 

■'’valSo) 

^SFc-oaa 


VAL(30) 

,  SFC-000 


AZA(31) 

90-160 


ghost SECTOR  (69) 


k°K  AiUTUDE  SECTOB 


SeCTOft 

^  =  125.750 

31  =  124.250 

32  =  133.720 
60  =  135.400 
69  =  111.100 
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I 
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Sr 
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GHOST  SECTOR  (69) 
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SECTOR  30  -  VALLEY 

LOW  ALTITUDE  SECTOR 

(HOT  SPRINGS(29)/VALLEY(30)  COMBINED) 


125.750 

124.250 

133.720 

135.400 

111.100 


GHOST  SECTOR 
(69) 
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GHOST 

SECTOR 
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VAL(30)  * 
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GHOST  SECTOR  (69) 
SFC-230 


Sector  31 
AZALEA 

1.  General  Information:  The  Azalea  sector  31  is  a  low  altitude 
sector  with  a  mixture  of  jet  and  general  aviation  traffic,  serving 
central  Virginia.  The  controller  serves  as  approach  control  for 
Charlottesville,  Harrisonburg/Staunton,  Virginia  with  a  VFR  tower 
at  Charlottesville.  The  sector  is  adjacent  to  approach  control 
facilities  to  the  east  and  north.  The  altitude  limits  are  16,000 
feet  and  below,  with  shelves  (see  attached  map)  .  The  two  VOR's  are 
Montebello  (MOL)  and  Gordonsville  (GVE) .  The  minimum  vectoring 
altitudes  are  3,000  to  the  east  rising  6,000  to  the  west. 

2.  Radio  Frecfuencies;  For  the  purpose  of  this  test  the  frequency 
for  the  Azalea  sector  will  be  124.250. 

3.  Procedures : 

A.  VFR  Towers; 

(1)  Center  Procedures: 

a.  All  flight  plans  shall  be  issued  to  the  tower 
at  least  10  minutes  prior  to  departure  time: 

1.  Aircraft  Id. 

2.  Type  A/C-Beacon  Code 

3 .  Route/Destination 

4.  Altitude  to  expect  10  min.  after  Dept. 

b.  All  inbound  flight  plans  shall  be  given  to  the 
tower  15  minutes  prior  to  Destination  time: 

1.  Aircraft  Id. 

2.  Type  A/C. 

3.  Type  of  Approach 

4.  Arrival  Time 

c.  When  towers  call  for  RLS  of  aircraft  the  center 
shall  issue: 

1.  Initial  HDG. 

2.  Initial  ALT. 

( 2 )  Tower  Procedures : 

a.  When  towers  call  for  RLS  they  shall  provide  the 
active  RWY. 

b.  Tower  is  responsible  for  the  visual  separation 
between  arrivals  and  departures. 

c.  Tower  shall  call  and  advise  the  center  when  an 
A/C  in  insight  landing  assured. 
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B.  Sector  Infonnationt 

(1)  Noh-turbojet  Baltimore,  Washington,  and  satellite 
arriyals  shall  enter  Casanova  sector  (69  Arrival 
Ghost)  at  or  below  9,000  feet  established  on  V143. 

(2)  Aircraft  landing  W16  and  MRB  shall  enter  Casanova 
sector  (69  Arrival  Ghostj  at  or  below  9,000. 

(3)  N6n-?turbo j et  Dulles  and  Satellite  arrivals  shall  be 
routed  via  V140  CSN  and  enter  Dulles  approach  in-trail 
with  constant  or  increasing  separation  or  vertically 
separated  with  the  faster  aircraft  at  90  and  slower 
at  70,  or  as  coordinated. 

(4)  Dulles  Tower  over  flight  traffic  shall  be  routed  via 
Vl43  and  handed  off  to  Casanova  (69  Arrival  Ghost)  at 
or  below  10,000. 

C.  Airspace  Inf ormat ion ; 

(1)  Shelves  in  sector  as  follows: 

a.  North  of  MOL  (at  and  below  160)  -  CSN  Lo  owns  170- 
27,0  for  metro  inbounds  (IDAr  DCA,  BWI) 
transitioning  traffic. 

b.  North  of  GVE  (at  and  below  130)  -  MOL-I  -  owns 
140^270  in  order  to  keep  lAp  departures  out  of 
Azalea  LO  sector. 

c.  Over  GVE  and  MOL  (at  and  below  160)  -  MOL-I  owns 
170-270. 
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Azalea  Sector  31  Facts  Sheet 

BWI,  DCA  and  SAT.  Arrivals  Handed  to  Ghost  sector  (69)  at  or  below 

9,000  est.  on  V143 

lAD  Over  flights  shall  be  routed  via  V143  at  or  below  10,000  and 
handoff  to  Ghost  (69) 


Valley 

sector 

30 

125.750 

Azalea 

sector 

31 

124.250 

Gordonsville 

sector 

32 

133.720 

Montebello 

sector 

60 

135.400 

Ghost  Departures 

sector 

57 

Arrival  Ghost 

69 

111.100 

Roanoke  Approach 

69 

111.100 

Lynchburg  Tower 

111.100 

All  Towers 

111.100 

All  VFR  towers  departing  RWY  36. 
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SECTOR  31  -  AZALEA 

LOW  ALTITUDE  SECTOR 


SECTOR  31  -  AZALEA 

LOW  SECTOR 


30  s  1 25.750 
51  s  154^250 
§2  s  133.720 
60  s  i  35.400 
69  s  111.100 
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Sector  32 
Gordonavllle  High 


1.  General  Descript ion :  The  Gordonsville  sector  (R32)  is  a  high 
altitude  en?-route  sector  extending  from  western  North  Carolina  to 
south  of  the  Washington,  D.C-  area.  The  basic  altitudes  are  FL240 
and  above,  with  two  shelves  •  fi'-^  attached  map) .  The  primary  VOR’s 
in  the  airspace  are  GVF  (Gore'  -^sville)  and  SBV  (South  Boston) . 

2.  Radio  Frequencies;  r--i  tt-i  y>%irpose  of  this  test,  the  frequency 
for  sector  32  will  be  133.720, 

3 .  Procedures ; 

A.  Sector  to  Sector. 

(1)  Raleigh-Durham  and  Greensboro  arrival  traffic  shall 
be  handed  off  directly  to  the  South  Boston  Sector 
(Arrival  Ghost  69) . 

(2)  Philadelphia  arrival  traffic  shall  enter  Brook  Sector 
12  (Arrival  Ghost  69)  at  FL290  or  below  unless 
otherwise  coordinated. 

(3)  Norfolk  and  satellite  arrival  traffic  from  over  PSK 
shall  be  descended  in  sufficient  time  to  comply  with 
procedures  listed  under  Montebello  (60)  sector 
(Aircraft  must  be  handed  off  to  sector  60  ASAP) . 

(4)  Baltimore  and  satellite  arrival  traffic  shall  enter 
the  Hopewell  sector  (arrival  Ghost  69)  at  FL290  or 
below. 

(5)  Washington,  Dulles,  and  satellite  arrival  traffic 
shall  enter  Blackstone  Sector  (Arrival  Ghost  69)  at 
or  below  FL250. 

B.  Sector  airspace  as  follows: 

(1)  J24  and  North  (at  and  above  FL280)  -  MOL-I  (departure 
sector)  owns  airspace  below  GVE-H. 

(2)  South  of  J24  (at  and  above  FL240) . 

(3)  GSO  shelf  (at  and  above  FL220) . 
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Sector  32  Facts  Sheet 

PKIs  Arrivals  4t  or  below  FL290  and.  handoff  to  Arrival  Ghost  69 
ORP  Arrivals  must  start  down  early  and  handoff  to  sector  60 
BWi  Arrivals  at  or  below  FL290  and  handoff  to  Arrival  Ghost  69 
lAD  Arrivals  at  or  below  FL2 50  and  handoff  to  Arrival  Ghost  69 


Valley  sector  3:^  125.750 

Azalt;.i  sector  31  124.250 

Gordohsville  sector  32  133.720 

Montebello  sector  60  135.400 

Departure  Ghost  51 

Arrival  Ghost  69  ill. 100 

All  Towers  111.100 


HIGH  ALTITUDE  SECTOR 


HIGH  ALTITUDE  SECTOR 


SECTOR  FREQs: 
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Sector  60 

MONTEBELLO  ^60^ 

If.  General  Description;  The  Montebello  sector  (60)  is  primarily 
an  intermediate  departure  sector  serving  the  Washing,  b.C. 
metropolitan  area.  The  altitude  limits  are  basically  17,000  - 
EL270,  with  two  shelves  (see  attached  map) .  The  two  VOR's  in  the 
airspace,  are  Montebello  (MOL)  and  Gordonsville  (GVE) .  Primarily 
a  departure  sector  for  lAD,  DCA,  BWI. 

2.  Radio  Frequencies ;  For  the  purpose  of  this  test,  the  frequency 
for  sector  60  Will  be  135.400 

3.  Procedures ; 

A.  Richmond  and  satellite  arrival  traffic  shall  be  descended 
in  sufficient  time  to  comply  with  procedures  listed  under 
Azalea  Sector  31  (Cross  20  west  of  FAK  at  9,000) . 

B.  Norfolk  and  satellite  arrival  traffic  shall  enter  the 
irons  Sector  69  =  Ghost  at  or  below  FL210. 

C.  Sector  airspace  is  as  follows: 

(1)  West  of  MOL  (FL240^FL270)  in  order  to  keep  TEC-H  from 
working  RIC  arrivals  for  approximately  10  miles. 

(2)  NE  of  GVE  (140-Ft270)  climb  corridor  for  BWI 
departures. 

(3)  East  of  CSN  (FL240-FL270)  climb  Corridor  for  BWI 
departures . 

(4)  Remainder  of  sector  FL170-FL270 

D.  Departure  routes  as  follows: 

(1)  IAD,DCA,BWI  -  FLUKY  GVE  flight  plan 

-  FLUiw  MOL065R  MOL  flight  plan 

(^):  ORF  -  ORF290R  to  join  MOL136R  MOL  J24.  . . 

(3)  RIC  -  RIC264R  to  Join  MOL130R  MOL  J24. . . 

E.  Arrival  altitude  information: 

(1)  RIC  arrivals  enter  MOL-I  at  or  below  FL250 

(2)  ORF  arrivals  Cross  20  West  Of  FAK  at  FL210 

Note:  lAD,  DCA  departures  will  be  climbing  to  FL210:  BWi 

departures  will  be  climbing  to  FL230  and  will  be  handed  off  to 
MOL-I  (R60)  by  DCA  approach  (57)=Ghost,  with  in-  Trail  spacing 
between  lAD  and  DCA  Departures  over  the  same  fix  (MOL  or  GVE) . 


c-24 


ORF  and  Sat.  Arrivals  20  West  of  FAK  at  FL210 
lAp/  DCA  departures  cliinbing  to  FL210. 

BWZ  departures  cliinbing  to  FL230. 


Valley 
Azalea 
Gordons  vine 
Montebello 
Ghost 

Arrival  Ghost 
Roanoke  Approach 
All  Towers- 


sector  30  125.750 

sector  31  124.250 

sector  32  133.720 

sector  60  135.400 

sector  57 

69  111.100 

69  111.100 

111.100 


SECTOR  60  ■  MONTEBELLO 

INTERMEDIATE  ALTITUDE  SECTOR 


0 


INTERMEDIATE  ALTITUDE 


INTERMEDIATE  ALTITUDE  SECTOR 


APPENDIX  D 
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(CONTINUED) 


Re^siUgn  Menu  Text  PVD  A  Trackball  designation 

List  (QP)  Trackball  to  desired  PVD  area. 


ROUTE  RADAR  CONTROLLER  DATA  LINK  CHART 

(CONCLUDED) 


Resend  a  Non-Wilcoed  Trackball  Same  message  types  as  for 

Message  — - t-t- —  deleting.  SVC  HE)  =  DL  service 

(SVGIP)  FMD  type(two  characters-TG,AA,FT) 
.  if  omitted  TC  assumed. 


